Content metadata directory services

ABSTRACT

Signals sensed from packaging of products are processed in a distributed reader and metadata routing system to provide metadata responses to mobile application programs. A routing system registers identifiers for different content ID schema. These identifiers are encoded packaging. Mobile device application programs are equipped with reader programs to extract identifiers from packaging. Metadata responses are identified by the ID provider of the content ID schema and extracted identifiers. The metadata routing system routes metadata responses to a requesting mobile device, supporting a variety of different ID providers and mobile device applications.

RELATED APPLICATION DATA

This application is a continuation of U.S. application Ser. No.14/977,278, filed Dec. 21, 2015 (now U.S. Pat. No. 9,892,206), which isa continuation of U.S. application Ser. No. 13/753,177, filed Jan. 29,2013 (now U.S. Pat. No. 9,218,429) which is a continuation U.S.application Ser. No. 11/614,942, filed Dec. 21, 2006 (now U.S. Pat. No.8,364,720) which claims the benefit of U.S. Provisional Applications60/747,408, filed May 16, 2006, and 60/753,257, filed Dec. 21, 2005,which are hereby incorporated by reference.

TECHNICAL FIELD

The invention relates to methods and systems for associating content,including both physical and electronic objects, with metadata throughnetworks.

BACKGROUND AND SUMMARY

This document uses the terms ‘content,’ ‘media’ and ‘media content’interchangeably to refer to pictures, music, movies and all of theirsundry creative brethren which collectively might fall under the grandumbrella named ‘creative works’. In general, a given creative work canbe thought of as an entity or ‘content object’, and either the creativework stands alone with the sole companion of a name or an identificationnumber, or it is somehow duplicated and packaged for a very wide varietyof distribution methods and channels.

In primarily the latter case, the concept of ‘metadata’ has gainedpopularity, referring to additional creative works which have some formof explicit or implicit relationship to a given singular content object.Metadata generally refers to information associated with a contentobject. Typically, metadata is often associated with multimedia content,like images, and video and audio programs, and is used to refer toinformation about the content, such as its source, owner, content title,etc. One of the simpler forms of metadata might be bit-fields describingadditional information about a content object such as an author's nameor a category that the content object might naturally fall under. Morecomplicated forms of metadata might be ‘pointers’ or addresses (e.g.URLs) of related content objects which, by reference, enable a user orconsumer to easily access that second content object. Most generally, akey concept from a content provider and/or content distributor's pointof view is that metadata can form an instant electronic relationshipbetween a consumer experiencing one of their distributed content objectsand themselves.

In this document, metadata refers to a broad class of informationrelating to a content object, and it applies to a broad class of contentobjects, including both physical and electronic objects. Metadata alsoincludes an instruction or set of instructions (possibly distributedover one or more devices) that is executed by machine or machines toperform a behavior associated with an object (e.g., perform an on-linetransaction, transmit or transfer content, authenticate/verify a user,content, access token, update/patch a program etc.). Metadata can beformatted and stored in a variety of formats. One format is XML, butthere are others. The metadata for a particular content object may bedistributed over different storage devices. In such a distributedstorage approach, the metadata in one location includes references tometadata in other locations (such an index, pointer, address, URL,etc.).

One aspect of the invention relates to the technical infrastructure,including metadata routing and associated network services that ensurethis electronic relationship can happen in the first place, and thatthis relationship can lead toward secondary revenue generationopportunities that may some day rival and eclipse primary mediadistribution revenue generation.

The business of selling packaged media or otherwise delivering specificmedia to a targeted audience has a long history of monetizing theprimary delivery of that media. Selling records or selling 30 seconds ofadvertising on a television show or selling tickets to a movie each fitinto the primary distribution monetization business model. The growth inthe Internet and the flowering of various digital distribution channelscertainly has complicated the description of primary media distributionitself, but the general notion of “packaging up” a creative work anddelivering it for some explicit compensation strategy remains intact.

In a kind of direct extrapolation of the primary distribution model,Digital Rights Management (DRM) inventions and approaches have at leasta decade worth of effort, design, trial, partial successes and valuablelessons now under their collective belt. Not least in these lessons arethe behind-the-scenes business community wrestling and clashes of Titanssurrounding the question on what might be considered a core property ofDRM approaches: “who owns the standard . . . who owns the channel . . .who ultimately owns the consumer relationship?” Phrased in this way,there can be little mystery why uniform global standards are possiblydecades away still.

Two somewhat different forces have arisen in the past decade or twowhich have not been entirely harmful to classic primary mediadistribution monetization, but they have nevertheless put significantpressure on businesses which rely on primary distribution revenue tolook for secondary methods of monetization. At the very least, theseforces have led toward fundamental changes of strategy in how primarydistribution methods are exploited.

The first force is the ease with which creative works can be copied andre-distributed in an unauthorized fashion. The second force is theadvent of highly distributed media distribution channels and the equallyhighly distributed end-devices used to experience a creative work, mostcertainly including mobile devices. Though these two forces are ratherdifferent from each other and though each has been partially transformedinto “opportunity” by ever-entrepreneurial efforts and companies, thefact remains that both forces are unstoppably disrupting traditionalapproaches to the monetization of primary media distribution.

The relative ease with which creative works can be copied has been aprimary fuel in creating the now familiar notion of peer-to-peernetworks where folks not only share pictures from family vacations butalso the latest movie they enjoyed last night. Untold years oftechnological ponderings and industry standards initiatives have soughtto re-establish the core role of primary packaged media distribution andits associated monetization, also not without some success, but thegenie does seem to be rather out of the bottle for those seeking tore-create the good old days of creation-to-consumption monetization.Coordinated primary and second monetization strategies andcash-generating mechanisms are inevitably here to stay, most likelyco-opting the second force of highly distributed distribution channelsand consumption devices. Of particular note is the up and coming‘mobile’ media consumption trend where ubiquitous connectivity meetsubiquitous delivery.

Still missing in this inevitable balancing of primary and secondarymonetization methods are the critical details of the secondarymonetization methods and systems, as well as the impact of theirexistence on primary distribution methods and strategies. In otherwords, how can secondary monetization work (beyond peddling primarydistribution of ring tones), and how can primary distribution productionprocesses be seamlessly modified to put the overall media industryprofit and revenue lines back onto positive and strongly growing paths?This document describes a routing system and method, along with detailedhardware and software descriptions of the system and network componentswhich can make it work in a tremendously complicated media distributionand consumption universe.

Managing the Fountain of Metadata

Once a distributor has accomplished primary delivery of a media objectto a consumer, the next best thing to “manage” is the metadata servicesthat add value to that delivered object. This is not the slippery slopenamed “control” which is a word written on many a tombstone of the lastdecade's worth of packaging and monolithic DRM-system approaches tomedia consumption behaviors, it is fundamentally about managing thehighest quality relationship to the individuals or groups who arenaturally attracted to the media content in the first place. The initialpackaging up of “good stuff” metadata into the primary delivery of theoriginal media content was one of the main reasons a consumer will pay amodest amount for the officially sanctioned media, but it will be theongoing access to high quality metadata, group affinities and seamlessaccess to related media which will compel honest consumers to be honest. . . they will simply get more value for their time and money that way.

Clearly, combining a media object with static metadata or even “staticlinks” to inherently dynamic web-based content is a developed art atthis point and somewhat accounts for the ongoing vitality of primarydistribution channels over some P2P network channels. In other words,packing in “good extra stuff” still sells records and movies andpictures. P2P copies can try to keep up, but the rightful distributorhas a leg up on the availability of legitimately compelling content,precisely because they are the legitimate owners or distributionrights-holder.

In some advertising-based business models, content objects aredistributed for free or reduced cost and provide a vehicle foradvertising revenue. These models provide an opportunity for contentowners to monetize content by conveying advertising within the content.Yet, to capitalize on this opportunity in distribution networks likewireless networks and the Internet, there is a need for mechanisms totie the content consumption to revenue opportunities, such as linkingthe content to electronic transactions to buy related content orproducts and services advertised within the content.

Fortunately, there are a few common denominators of all mediadistribution and media consumption that will never go away and which getto the heart of ensuring a stable relationship between content providersand content consumers. One common denominator is simply identity of thecontent itself. Another common denominator is the existence of basicbusiness rules and legal frameworks which collectively define the commonsense notion of “legitimate distribution and consumption” and itsassociated notion of return on investment to the content providers. Athird common denominator is the near-universal desire of consumers tohave access to the best information related to the content beingconsumed. And finally, there is a fourth common denominator that acontent provider wants to own the “rules of relationship” associatedwith the content they distribute: Business rules and contracts shoulddefine how legitimate and consumer-friendly metadata relationships arecarried out.

One aspect of this disclosure refers to this notion as the title of thissection indicates: managing the fountain of metadata that a consumerwants and will eventually expect. The other side of this coin is classicbusiness principle behind satisfying customers: delivering the highestquality “rewards” in managing this fountain will ensure repeat business.

The raw mechanics of how this management can happen in the globalcacophony of media flow provides the technical foundation for theseemerging content distribution and monetization models. The carefulreader will see that the described system and network mechanisms arefully complementary to DRM-based approaches in the “digitally contained”world of the Internet and classic dedicated media channel deliverynetworks on the one hand, and fully able to deal with complexities andsteep growth of mobile device consumption on the other hand.

In one embodiment illustrated in FIG. 9, a routing system includes twoprimary processing engines that are used to link a media object held bya consumer to a source of metadata. The first engine, including the IDresolver and registry components, can be described as the lingua francaof identification systems, methods, technologies, etc. It can also beeffectively described as a virtual “DNS for Content Objects,” as thisidentification engine respects any and all native or monolithicapproaches to content identification. Hence the qualifier “virtual” infront of DNS. Its function is to resolve a content ID based onidentifying information originating from disparate contentidentification systems.

The second engine, the rules database and processor, determines where tore-direct the consumer based on the resolved content ID. This rulesengine facilitates secondary revenue generation opportunities because itfurther enables the system to tailor the metadata response to providerelated content, products and services. The content provider universe iscomplex and often has a wide variety of business interests at play. Suchinterests are most often encapsulated in contracts between variousentities, including the artists which create works in the first place,and such contracts can be extended to the detailed rules of metadataresponse to normal and/or pro-active metadata requests during mediaconsumption sessions. The quality of the response to the consumer, andthe opportunity to direct consumer's to additional revenue generatingactivities including classic eyeballs/advertising pathways, can beenabled by this rules engine.

FIG. 9 shows the first and second engines as being part of a routersystem, these engines can be partitioned and distributed over devicesand controlled by different participants. The rules processor anddatabase may be partitioned from the router system and implemented inseparate instantiations, each controlled by a different participant. Inthis case, for example, the resolver re-directs a consumer to a rulesengine under the control of a participant linked to the object via theID registry, and this rules engine, in turn, executes a rule thatdetermines the metadata response for the consumer (e.g., a URL or set ofURLs to particular metadata). The rules processor may also be executed,at least in part on a device under the client's control. In this case,for example, a set of URLs linked to the content object via the IDregistry are returned to the client, which in turn, executes rules todetermine the metadata response tailored to the consumer.

The good old days of selling packaged media is still with us. Thecontent being sold is now the seed for an ongoing relationship in waysthat classic “branding” could barely fathom. This disclosure details howthese two core engines can be built and operated for the good of contentproviders and content consumer's alike.

Managing the Relationship Between Metadata and Content Objects

As noted, metadata plays an important role in managing and facilitatingtransactions in content objects. Some significant examples include theuse of metadata in digital distribution of content, electronic commerce,and on-line searching and organization of vast stores of data (e.g., theInternet). As the digital world proliferates and there are numeroustransactions in content objects, there is a compelling need to managethe association of metadata and content objects.

This need is not confined to the digital realm. Because humans live inthe physical and analog realm, there will always be a need for efficientschemes for crossing back and forth between the digital and analogrealms. In particular, physical objects have corresponding metadata justas electronic objects do. For example, products have correspondingmetadata in the form of product information, manuals, catalogs ofrelated products, etc. Printed objects have metadata in the form ofelectronic versions of the object, ownership, source, time and locationof creation, etc. Physical objects link to their metadata via anidentifier on or derived from the product or related documentation(e.g., packaging, labels, etc.). Metadata management technologies, thus,need to be able to support this physical/electronic interface. Emergingapplications include linking physical objects to Internet relatedinformation and electronic transactions as described in U.S. Pat. Nos.6,947,571 and 6,505,160 and International Patent Application WO97/43736, which are incorporated by reference.

A significant aspect of managing metadata of disparate content objectsis providing effective technologies and schemes for contentidentification. This is important in the digital realm, where there aremany potentially conflicting content identification technologies andarchitectures. It is also important for managing metadata for physicalobjects in the digital realm, where identifiers extracted or derivedfrom physical objects provide a form of digital identity of the physicalobject in the digital world. The metadata systems and methods in thisdocument are designed to work with identification systems that operatein the digital realm only, as well as ones that span the digital andphysical realms. The latter category includes identification methodsthat derive content identifiers from an electromagnetic signal capturedfrom an analog representation of audio or images (e.g., a digitalwatermark, content fingerprint, visual symbology, pattern recognition,voice recognition, OCR, etc.) as well content identifiers read viaelectromagnetic readers of physical data carrier devices like magneticstripes (and other magnetic data carriers), RF ID tags, smart cards,etc. For example, physical object can be identified via RFID tags, asdescribed at www.epcglobalinc.org and in the overview document(www.epcglobalinc.org/news/EPCglobal_Network_Overview_10072004.pdf),which is incorporated by reference.

Such content identification technology provides a means to identifycontent objects, but the variety of content identification schemes andformats poses compatibility and interoperability challenges. Moreover,such systems cannot provide useful information without an effectivesystem and method to associate various identifiers with the appropriatemetadata.

The problems are multifold and created by the fact that digitaldistribution separates content from packaging, new 1-1 marketingopportunities are minimally being utilized, and digital distribution ismoving forward with proprietary channels that make the value chain morecomplex rather than simpler.

For instance, once content is digitized information typically carried onphysical packaging is lost from the content. Digital downloads arepartial products, “files without packaging and related metadata”.Metadata loss is central to issues surrounding digital contentmanagement, piracy and e-commerce. Manual population of multipledistribution channels' metadata repositories gives rise to human errorand inaccurate metadata.

Marketing opportunities are being lost once content is distributed sincecontent owners and retailers lose contact with the consumer. Loss of 1-1marketing capabilities, especially with digital distribution gainingtraction, leads to loss of potential revenue.

Channels of distribution (e.g., online music retailers, podcasts, socialnetworking sites, user-generated content sites, and P2P networks) andthe number of digital derivatives (ring tones, mobile videos, etc.)stemming from a single digital product are increasing. Accurate andeffective content identification is an absolute requirement to managecontent effectively. Content owners are currently evaluating theirmetadata repositories trying to understand how to streamline in a mannerthat is cost-effective.

Proprietary content identification and metadata systems complicate,rather than simplify, the value chain. Content is embedded with manyidentifiers that do not interoperate. A few proprietary systems arelinking content to metadata without input of the content owners, thusincreasing the number of value chain participants.

Previous initiatives to create a central content metadata repositoryhave failed due to proprietary, political and technical issues ofcreating a repository rather than directory service. Content owners andretailers want to manage their proprietary metadata and participate inbuilding the relationship with the consumer. Third party metadatacompanies, and related companies, such as those that organize, classify,search and provide search results based on metadata (such as searchengine providers), stand to profit from potential unauthorized use ofcontent owners' metadata.

This document describes systems and methods for associating metadatawith content objects. It describes embodiments of novel routing methodsand systems referred to as content metadata directory services.

Globally Unique Identifier Scheme

One novel method of associating a content object with metadata uses acombination of a content identifier and a bounding identifier to enablehandling of disparate sets of content identifiers for content objectswith potentially conflicting content identifiers. The method receives acontent identifier for a content object from among a set of contentidentifiers. It provides a unique bounding identifier for the set ofcontent identifiers. This unique bounding identifier is used incombination with the content identifier to form a globally uniqueidentifier for the content object. This globally unique identifier isassociated with a metadata source, which enables routing of a user tothe metadata source.

This approach effectively manages cases where an ID provider pre-assignsa set of content identifiers to objects, and then later registers themin our novel directory system. It also manages cases where the directorysystem assigns the content identifier prior to insertion of the contentidentifier in the content object by an ID provider.

As set forth in the CMDS embodiments, the unique bounding identifier maycomprise an ID provider identifier. For example, RFID, EPC, digitalwatermarking and fingerprinting technology providers can serve as IDproviders in the system with overlapping content ID numbers, but uniqueID provider IDs. Each ID provider may also use an ID version todistinguish different versions of its technology or content ID spaces.

After appropriate registration, the directory system is used to routeusers to a metadata source. For example, the user (e.g., the readerexecuting on the user's device) provides the content ID from the contentobject and the bounding identifier. The directory system, in turn,routes the user to the metadata source associated with the globallyunique identifier for the content object.

Metadata Directory Supporting Content Objects with Multiple ContentIdentifiers

Another novel method addresses content objects with two or more contentidentifiers, potentially referencing different metadata sources. Thismethod registers different globally unique identifiers for a contentobject. These globally unique identifiers each comprise a contentidentifier provided with the content object and a bounding identifieridentifying a set of content identifiers of which the content identifieris a member. For each of the globally unique identifiers, information ismaintained about a metadata source. The method receives a first contentidentifier for the content object, and uses a bounding identifierassociated with the set of the first content identifier to determine theglobally unique identifier for the first content identifier. The user isrouted to the metadata source associated with globally uniqueidentifier.

This approach handles a variety cases in which two or more contentidentifiers are provided for a content object for the purpose ofregistration or resolution. The metadata directory system supports andmanages both the registration of and routing to different metadatasources corresponding to different content identifiers of the contentobject. These cases include:

1. Content identifiers are embedded or calculated by different IDproviders and are later derived from the content object using differentreaders associated with those technologies. For example, the readers aredifferent because they derive the content identifier using differentcontent identification methods (e.g., through the file header/footer,digital watermark, fingerprint, Vertical Blanking Interval data in videoprogramming, etc).

2. The different readers may, for example, derive the contentidentifiers using different attributes of the content object. Thesedifferent attributes may comprise different types of embedded auxiliarydata (different watermark embedders/readers, watermark vs. embeddedheader/footer data). These different attributes may comprise attributesfrom which different digital watermarks or robust hashes are derived.The different attributes may correspond to in band and out of bandattributes of the content object. “In band” refers to an identifierderived from content in the content object that is rendered forperception by a human. “Out of band” refers to auxiliary data carried inthe content object but not forming part of the content that is renderedfor perception by a human. Certain types of content objects includemultiple content programs rendered for perception by a human, like videoand audio tracks and close captioned text. In band identifiers may bederived from one or more of these content signals within the contentobject. In some cases, one content program may be embedded in anothercontent program within a single content object, such as where closecaptioned text is embedded in the audio or video program of anaudiovisual work.

3. The different content identifiers for a content object may be derivedfrom the content object using different parts of the content object,including different in band and out of band parts as well as differentparts within the in band portion of the object and different partswithin the out of band portion. These parts may be in discrete locationsin one domain of the content signal, yet at overlapping locations inothers. Examples of domains include spatial, temporal and transformdomains (e.g., frequency domain, compressed domain, etc.) of the contentsignal in a content object).

Enabling Different ID Provider and Content Provider Participants

In some metadata systems, the system owner, serving as a registrationauthority (RA), provides the identification technology and contentowners use the technology to register themselves as a content provider,register content and link the content to metadata.

This document describes a novel system that enables multiple identityproviders (ID Providers) to register and use the system. The ID Providerregisters with a metadata directory system, receives a unique boundingidentifier, and uses this bounding ID (e.g., an ID provider ID) withsubsequent interactions with the metadata directory system. Separately,metadata source providers register metadata sources with the metadatadirectory system. This enables many different participants to associatecontent objects with metadata sources using one or more identityproviders. Examples of metadata source providers include contentproviders, like content owners or retailers that have the flexibility ofworking with different ID providers to associate content objects withmetadata. Both content providers and ID providers can register and usethe system. The metadata source is the system or device that providesthe metadata, like a web site. The directory system uses an identifierfor the metadata source, which enables it to maintain an associationbetween a content object and its corresponding metadata source. Forexample, in some embodiments, a URL serves to identify the location ofthe source.

One embodiment of the directory system is referred to as CMDS. CMDSenables content providers to utilize the CMDS to knit together metadatasources that are associated with content using disparate and previouslyincompatible ID provider technologies. CMDS enables content providers tomanage their proprietary information (i.e. they do not have to turn overcontrol of proprietary metadata to a RA for storing and distributing themetadata), enables eCommerce for all value chain participants (e.g.,both content owners and retailers can embed CIDs), facilitatesinteroperability with all content identity provider technology (evenpre-existing ID systems, such as EPC), allows for compatibility withboth PC and mobile devices, facilitates interoperability for multiple IDproviders who license a common identification algorithm, and enablesusage reporting and vital marketing statistics.

One aspect of the invention is a system for processing audio to providemetadata responses to different mobile device application programs withcorresponding content ID schema. Audio signals are processed in adistributed reader and metadata routing system to provide metadataresponses to mobile application programs. A routing system registersidentifiers for different content ID schema. These identifiers areencoded in audio signals. Mobile device application programs areequipped with reader programs to extract identifiers from audio sensedby the microphone of a mobile device. Metadata responses are identifiedby the ID provider of the content ID schema and extracted identifiers.The metadata routing system routes metadata responses to a requestingmobile device, supporting a variety of different ID providers and mobiledevice applications.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram illustrating a method of associating a contentobject with a metadata source.

FIG. 2 is a flow diagram illustrating interaction between a reader and adirectory system to link a content object with a metadata source.

FIG. 3 is a system diagram illustrating a metadata directory system andits interaction with ID providers for registration of content IDs andreaders for resolution of content IDs.

FIG. 4 is a system diagram illustrating an overview of a contentidentification and routing system.

FIG. 5 is a diagram demonstrating a usage model of using the routingsystem to direct a user to content providers based on contentidentifiers extracted from the user's content object.

FIG. 6 is a diagram illustrating an implementation of a router in moredetail.

FIG. 7 is a diagram illustrating a distributed router system in oneimplementation of a directory system.

FIG. 8 is a diagram illustrating an example of a directory systemarchitecture along with different content owner participants using thesystem to associate content identifiers with metadata sources theycontrol.

FIG. 9 is a diagram illustrating a routing system including a rulesprocessor and traffic monitor.

DETAILED DESCRIPTION

FIG. 1 is a flow diagram illustrating a method of associating a contentobject with a metadata source. This diagram is intended to show how acontent metadata directory system performs registration of content IDs,which achieves two objectives:

1. it enables integration of different content identification schemeswith potentially overlapping content ID schema; and

2. associates the each content ID with one or more metadata sources.

As shown in block 100, the directory system receives content IDs. Thesecontent IDs either originate from pre-existing sets (e.g., pre-assignedby an ID provider), or directory system itself issues content IDs for anID provider upon request. The ID provider refers to an entity thatprovides content identification for content objects. Typically, this isa content identification technology provider, such as a providertechnology for computing in band (e.g., watermarking or fingerprinting)or out of band identifiers (DRM container technologies, VBI inserters,etc.) for content objects.

To differentiate among different sets of content IDs, the directorysystem provides a unique bounding identifier (BI) as shown in block 102for each unique set of content IDs registered in the directory. Itensures that BI's for different sets of content IDs do not collide.Thus, while it is possible to register pre-existing BI's that do notcollide, it is preferable for the directory system to issue the BI's orat least issue guidelines for their use to prevent collisions.

The directory system forms globally unique identifier (GUI) for allcontent objects that it manages by combining the content ID for anobject with the BI for the set of content IDs of which the content ID inquestion is a member (block 104).

The directory system associates the GUI for a content object with ametadata source as shown in block 106. As explained below, this metadatasource provides metadata in response to a request from an entity thatsupplies the content ID for a content object. The directory systemstores the association between the GUI of a content object and themetadata source in a manner that enables fast, efficient routing of therequesting entity to the metadata source. In one implementation, thedirectory system stores a location of the metadata source on a network,such as a URL. This enables the requesting entity to connect to themetadata source and retrieve metadata associated with the contentobject. Several metadata sources may be associated with a GUI andreturned to a requesting entity.

FIG. 2 is a flow diagram illustrating interaction between a reader and adirectory system to link a content object with a source of metadata. Asshown in block 110 the reader extracts a content identifier from acontent object. It then forwards the content ID to the directory systemand either implicitly or explicitly identifies the BI for the set ofcontent IDs in which the extracted content ID is a member (112). Anexample of explicitly identifying the BI is where the reader supplies aunique provider identifier assigned to it, along with a versionidentifier. The version identifier may be used to enable the provider ofthe identification technology to create different content ID sets, whichenables flexibility with different versions and upgrades of the IDprovider's technology. Some examples include different versions of aparticular RFID, bar code, digital watermarking, fingerprinting or DRMtechnology for different customers, applications or content objectgroupings.

An example of implicitly identifying the BI is where the directorysystem determines the identity of the provider based on some inherentattribute of the data provided by the reader, such as its format, datatype, etc.

The directory system forms the GUI using the received content ID fromthe reader and the BI (114). The precise manner of formation may vary.One approach is to concatenate the content ID and BI in some fashion(e.g., appending them together to create one GUI). Another approach isto hash one or more parts of the content ID and BI and combine theseparts to create one GUI. It is possible that one or more third partiesmay be involved in the process of supplying the content ID and BI partsof the GUI. For example, a fingerprinting database may supply thecontent ID and the BI associated with it. Yet another approach is thateach ID is located in a separate field in the database, and only entriesthat match all ID fields are used to register or resolve the GUI. Thedirectory system maps the content ID and BI into a naming, numbering oraddress space which provides a GUI for each content object.

The directory system then looks up the metadata source or sourcesassociated with GUI (116) and returns some identification of the sourceto the reader. One form of source identification is its URL, but otherforms of identification are possible as well. Examples include apointer, address, index to a database of metadata, machine instructionfor accessing the source. The approach of returning an identification orlocation of the source to the reader enables the reader to establish adirect connection with the source to get the metadata. In alternativeapproaches, the directory system can instruct the source to establish aconnection with the reader by providing the reader's address. Thedirectory system may also act as an intermediary between the reader (orlocation specified by the user of the reader), on the one hand, and themetadata source on the other. This approach can be used where thedirectory, or some other intermediary in communication with it, is usedto provide additional processing of the metadata before supplying it tothe requesting entity at a location of the requesting entity's choosing.

FIG. 3 is a system diagram illustrating a metadata directory system andits interaction with ID providers for registration of content IDs andreaders for resolution of content IDs. As shown, different ID providersystems 200, 202 establish sets of content IDs corresponding to contentobjects. The ID provider systems may pre-assign sets of content IDs toobjects and then register with the directory system 204 them via thedirectory system's registration interface 206. Or, they may request thedirectory system 204 issue content IDs via the registration interface206.

The directory system includes and/or communicates with a database 208that stores the association of the GUI 210 for each content object andits corresponding metadata source ID 212. FIG. 3 shows a generalizationof the association of a GUI to a corresponding metadata source. Thisdatabase can be structured with one or more layers of indirection inwhich aspects of the GUI are used to index into different handlersand/or databases segmented by provider, version, location, etc.

FIG. 3 illustrates the point that different ID providers (e.g.,providers A and B) or different versions of a single provider'stechnology (Versions A and B) can register multiple sets of content IDswith the directory system. Moreover, multiple content IDs from differentsets may be associated with the same content object 214. For example, IDprovider A and ID provider B distribute readers A and B (216, 218),respectively. These readers may be programs, devices, or a combinationthereof (including components of a device or distributed over differentdevices, such as in a web services type implementation). In thisdepiction, content object 214 includes CID 1 of set A (220) and CID 1 ofset B (222). A single program or device such as a media player programor device may include both readers A and B and present a commongraphical user interface to the user. Alternatively, the readers may beseparate components or programs executing within the user's device ornetwork domain.

When the readers 216, 218 encounter the object, such as upon fileopen/copy/transfer/edit command, entry into a device, network gateway orfilter, they extract the content ID and forward it (along with theimplicit or explicit BI data) to the directory system's resolutioninterface 224. The resolution interface, in response, looks up themetadata source ID or IDs if there are multiple sources (e.g., a URL orset of URLs) and returns them to the respective readers (or some programor device designated by the readers or pre-registered with the directorysystem).

The readers 216, 218 then use the metadata source IDs to establishconnections with the respective metadata source provider systems 230,232 and get the metadata associated with the content object 214 fromthese different sources. For example, these sources may be web contentfiles on web servers located at the location returned by the directorysystem. These sources may be maintained or controlled by differentparticipants in the content distribution value chain, such as contentowners, retailers, catalog companies, product manufactures, serviceproviders, etc. One source of metadata may be the content owner, whichprovides web content affiliated with the content owner, and anothersource of metadata may be the content retailer, which provides webcontent affiliated with the retailer (e.g., such as eCommerceopportunities to buy related entertainment content or merchandise).

The specification provides detailed embodiments of technology summarizedabove as well as additional inventive systems and methods. FIGS. 4-8 arebriefly summarized here, are further illustrated with examples inconnection with a system called CMDS.

FIG. 4 is a system diagram illustrating an overview of a contentidentification and routing system.

FIG. 5 is a diagram demonstrating a usage model of using the routingsystem to direct a user to content providers based on contentidentifiers extracted from the user's content object.

FIG. 6 is a diagram illustrating an implementation of a router in moredetail.

FIG. 7 is a diagram illustrating a distributed router system in oneimplementation of a directory system.

FIG. 8 is a diagram illustrating an example of a directory systemarchitecture along with different content owner participants using thesystem to associate content identifiers with metadata sources theycontrol.

As summarized above, the system works with many different contentidentification technologies for both electronic and physical objects. Italso applies for both out of band and in band content identification.Examples of out of band content identification for content objectsinclude identification based on auxiliary data in file headers andfooters, Vertical Blanking Interval (VBI) inserted data, DRM containerschemes for identifying content signals in the container, etc.

The following describes some examples of in band content identificationin more detail.

Digital Watermarking

One method for in-band content identification is to carry a contentidentifier in a digital watermark embedded in the perceptual portion ofa content object that is rendered for display or playback to a human.The digital watermark is hidden or “steganographically embedded” in thecontent by modifying the content to include an auxiliary signal thatconveys auxiliary data (e.g., a message “payload”), such as the contentidentifier.

Digital watermarking is a process for modifying physical or electronicmedia to embed a hidden machine-readable code into the media. The mediamay be modified such that the embedded code is imperceptible or nearlyimperceptible to the user, yet may be detected through an automateddetection process. Most commonly, digital watermarking is applied tomedia signals such as images, audio signals, and video signals. However,it may also be applied to other types of media objects, includingdocuments (e.g., through line, word or character shifting), software,multi-dimensional graphics models, and surface textures of objects.

Digital watermarking systems typically have two primary components: anencoder that embeds the watermark in a host media signal, and a decoderthat detects and reads the embedded watermark from a signal suspected ofcontaining a watermark (a suspect signal). The encoder embeds awatermark by subtly altering the host media signal. The readingcomponent analyzes a suspect signal to detect whether a watermark ispresent. In applications where the watermark encodes information, thereader extracts this information from the detected watermark.

Several particular watermarking techniques have been developed. Thereader is presumed to be familiar with the literature in this field.Particular techniques for embedding and detecting imperceptiblewatermarks in media signals are detailed in the assignee's U.S. Pat.Nos. 6,122,403 and 6,614,914, which are hereby incorporated byreference.

Robust Content Hashes and Fingerprinting

Another method of in-band content identification is a hash of thecontent data, which is sometimes referred to as a content “fingerprint.”In order to remain unchanged through distortion of the content, a robustform of hash is sometimes used in which the hash is derived fromfeatures of the content that are expected to survive in tact throughdistortion in the delivery channel, like clipping, time or geometricchanges, compression, transmission, etc. Examples of these featuresinclude a vector of frequency domain values (e.g., e.g., robust low andmid frequencies), perceptually important features (including temporal,spatial or frequency domain features), content statistics, featurevalues quantized into discrete bins, all of which are not necessarilymutually exclusive, and which are generally characterized in that theyare not degraded by expected distortion in the channel (e.g.,compression, transmission, D to A, and A to D conversion). To be clear,robust fingerprinting methods allow some change in the content signal,yet the fingerprint computed from that distorted signal still maps tothe same identifier. In other words, expected degradation does notchange the signal so substantially that it maps to a differentfingerprint in the database or no fingerprint at all. For consistency,we refer to these methods as fingerprinting, which generate contentfingerprints.

This fingerprinting approach to content identification has the advantagethat the auxiliary data embedding process is unnecessary. Instead, thereader process can generate the identifier from the content objectwithout prior explicit modification of the content object to includeauxiliary identifying data. A potential disadvantage is that copies ofthe same content program (e.g., the same musical track, song, movie)have the same fingerprint, which requires use of additional means todifferentiate different copies of the same content program. Theadvantage of not requiring auxiliary embedding is also mitigated by thefact that the fingerprint needs to be registered and kept in afingerprint database to enable matching of a computed fingerprint withregistered fingerprints. Once a match is found, the database providesthe content identifier for the matching fingerprint. This potentiallyadds additional processing and network communication to produce thecontent identifier.

For ease of understanding in the context of our architectures, wedescribe fingerprint methods as including three components, acalculator, a reader and a fingerprint database. The calculator does thefollowing: (1) creates the fingerprint using the same (or similar, wherechanges are based upon known or estimated distortion) algorithm as thereader, (2) registers the fingerprint in the fingerprint database, and(3) links the fingerprint to a content identifier. The fingerprint maybe one value or a set of sub-fingerprints taken from portions of contentthroughout some or all of the content. When sub-fingerprints are used,each sub-fingerprint or set of sub-fingerprints links to the samecontent identifier. The reader computes a fingerprint (e.g., set ofsub-fingerprints), sends them to a fingerprint database, and receivesthe content identifier.

The fingerprint algorithm, as used in the calculator and reader,utilizes the perceptual content signal. The fingerprint is a numericalconstruct (e.g., an array of values) derived from a content signal thatserves as a statistically unique identifier of that signal, meaning thatthere is a high probability that the fingerprint was derived from thecontent signal in question rather than a different one that sounds orlooks similar. One component of fingerprint algorithm is a form of hashalgorithm. The hash algorithm may be applied to a selected portion of acontent signal (e.g., the first 10 seconds) to create a fingerprint, ormay be applied repeatedly to generate a sequence of robust hashes, wherea specified sub-set of this sequence can identify content. For example,the sequence may use sub-fingerprints from every 1/16 second of a song,and require 32 sub-fingerprints (i.e. any 2 seconds of audio) toidentify the audio. In addition, 3 seconds can be used to improveaccuracy.

Directory System Applications

As noted, the directory system and method are applicable to bothelectronic and physical content objects (as well as objects that pass toand from analog and digital domains). The network methods forcommunicating and routing a device (such as computer or wireless phonehandset) having a content object to another having metadata relating tothe content object apply to different types of networks, includingcomputer networks like the Internet, and wireless telephone networks.Examples of mobile device applications, such as linking from an objectto its metadata via a cell phone handset, are described below. Therouter can be implemented in the cell phone network, the Internet, orspanning both the cell phone and Internet, such as when mirror routersreside in the cell phone network, the Internet or both the cell phoneand Internet network. Different types of URLs such as WAP, WMI and“full” may be used as metadata source identifiers maintained in thedirectory system.

Metadata Routing and Rules

A content metadata directory system enables those having control over acontent object to associate a metadata response with the content. Inmany applications, it is advantageous to allow different metadataresponses for a particular content object. We refer to the instructionsand/or data within the system that control the metadata response as“rules.” One example of a rule in the directory system is data orinstructions specifying the URL or list of URLs to return in response toa metadata request specifying a particular content ID. In some cases,more complex rules are needed to support metadata responses tailored toa particular context, such as user attributes (e.g., user preferences,security, account information and status, location, etc.) or transactionattributes.

To illustrate an implementation of these rules, it is instructive tobegin with a diagram showing the components of a router system in whichthese rules operate. FIG. 9 is a block diagram illustrating a routersystem and its relationship with a consumer and content distributionparticipants. In this diagram, there are at least three entitiesrepresented: the consumer, the router service provider(s) and contentdistribution participants. FIG. 9 shows a configuration in which thecomponents of the router system are distributed across theseparticipants. The components comprise devices and/or software modulesand examples of these are provided throughout this document. One set ofcomponents are referred to as part of the consumer domain 900. These arecomponents that the consumer control's such as his or her devices andembedded software in these devices (such as wireless phone, homenetwork, PC, home entertainment system devices, etc.). Another set arereferred to as the router system 902. These are components involved inrouting from content identification and related context to a metadataresponse, as well as related network services, such as metadata trafficmonitoring and response aggregators. A final set are referred to as thecontent distribution participants 904. These are the participants thatprovide content objects, manage their distribution, and supply and/orcontrol metadata content distribution.

The content distribution participants 904 include, but are not limitedto, content owners 906 and content distributors 908. These ownersinclude not only traditional providers of entertainment content, butalso those that provide content, including advertising, used to marketother products and services. These participants register their contentobjects 910 with the router system 902 and distribute them to consumers912. Through a registration component 914, the participants 904 registertheir content objects in the routing system as described in the variousembodiments in this document. In particular, they provide contentidentifiers and associated rules for providing responses to metadatarequests for these identifiers. These content identifiers and rules arestored in an ID registry database 914 and rule database 918,respectively. These databases may be integrated in one database orimplemented in separate databases with a key or like identifier (e.g.,unique identifier) that associates a content object with a correspondingrule governing the metadata response.

The router system enables consumers to request a metadata responsewherever the content object travels in its distribution chain as long asthe consumer has a reader to extract a content identifier and associatedmodules for packaging and sending a metadata request to the routersystem. FIG. 9 illustrates the metadata request as an “ID labeledrequest” from the consumer domain. The “consumer domain” in this contextis not intended to be limited to only retail users of content. Rather,it includes virtually any user of the router system whether theyrepresent content owners or distributors seeking to access metadata fortheir content, purchasers/licensees of the content, or customers thatreceive and consumer content for entertainment, information or commerce.In fact, rules help facilitate different levels of access among thevarious types of consumers of the router system.

The router system includes an ID resolver 920, which receives the IDlabeled request and determines an ID for the content object based on thecontent ID and associated identification system information supplied bythe requesting device. The discussion for mapping content identifiersand provider identifiers into a unique identifier for a content objectis one example of such a process. This approach of unifying contentidentification schemes enables the routing system to serve as a form oflingua franca for content identification, stitching together disparatecontent naming schemes.

The content ID may have one or more metadata responses registered forit. A rules processor 922 executes rules associated with the contentobject (e.g., via the content ID) to determine the metadata responsebased on information supplied in the request, information about therequesting user (including the user's device capabilities, connectivity,etc.), and/or information retained in the routing system, such astransaction data for the content object or the class from which it thecontent object originates (class defined by content genre, by affinitygroup of consumers for the content genre, etc.).

In addition to resolving IDs and executing rules for content objects,the routing system may also provide additional services. The routersystem of FIG. 9 includes a traffic monitor 924, which logs usagestatistics and generates usage reports. An embodiment of this usagemonitoring and reporting is described with reference to CMDSimplementations below.

The rules processor can also execute rules based on a content object'sdynamic metadata. Dynamic metadata refers to metadata that change overtime. One example of such dynamic metadata is a content object's usagedata. A rule governing the metadata response can be made dependent onthe usage data. For example, if the number of requests for metadataexceed a threshold, the metadata response is adapted accordingly. Forexample, more metadata data including information about related contentand commerce opportunities are provided as the interest level in aparticular object increases over time. The response can be tailoredbased on user information derived from metadata requesters so that theresponse is tailored to the common attributes of the class of usersrequesting metadata for the object. Patterns of common attributes ofusers, content or the content metadata emerge as usage data is trackedover time. This enables the system to identify and dynamically addmetadata responses for a content object. For example, as interest in thecontent object grows, the routing system adds additional links torelated content objects and products and services to an affinity groupfor a content object or class of object. The affinity group can bedefined, for example, as a group with common preferences or interests incontent objects.

As a further service, the routing system can also act as a metadatarepository and aggregator of metadata responses. FIG. 9 includes aresponse aggregator 926, which provides metadata responses and storesmetadata for content objects in support of this function. In someembodiments, the routing system simply re-directs the metadata requestto the content owner/distributor, which in turn, provides metadata tothe requesting consumer. There are alternative ways to implement thisapproach. One, as documented in CMDS embodiments, is to return to theconsumer a URL or set of URLs for a metadata sources controlled byothers. The consumer's device (e.g., via a web browser or likeapplication program) then sends a request for metadata to the metadatarepository at this URL. Another approach is to act as a proxy server forthe content owner's metadata repository. In this case, the routingsystem determines the metadata source's URL based on ID resolution andrule execution (if rules exist) and issues a metadata request to themetadata repository at this URL. If multiple URLs are involved, it makesa query to each one. The routing services aggregate the metadataresponses from the metadata repositories and returns the aggregatedmetadata to the requesting consumer. Another approach is where therouting system forwards the metadata request from a consumer to the URLof a metadata repository, which in turn, responds with metadata directlyto the requesting consumer. In sum, the content owner/distributorcontrols the metadata response in some cases as shown in block 930,where as the routing system controls the response in the other case.

As an added function, the routing service acts as a metadata repository.In cases where a rule dictates it, a user requests it or other metadatasources are not available, the routing system identifies the URL of themetadata repository within its control, packages the metadata responsewith the response aggregator and returns the metadata to the requestingconsumer.

The capability of serving as a metadata repository enables the routingsystem to provide additional network services. One such service is toenable users the ability to collaborate in the creation of metadata forcontent objects by posting recommendations, preferences, and otherrelated information about content objects in the metadata repository.This adds an added dimension to affinity groups identified and managedby the routing system. In particular, it enables members of these groupsto be active contributors to the metadata for the content objects thatthey are most interested in.

Having described the routing system, we now describe rulesimplementations in more detail. One approach to supporting multipledifferent rules for a content object is to enable one or moreparticipants that control the object to register different content IDsassociated with that object in the ID registry, each having anassociated URL or set of URLs in the registry database. For example,each content ID references a URL for the respective participant (e.g.,content owner, distributor, retailer, each providing different metadatasources at the corresponding URLs in the database).

This approach may lead to further rules being implemented in the routersystem and/or client program executing in the consumer's device. Forexample, the process begins with a client reader program or programs onthe consumer's device extracting multiple CIDs from the content objectand forwarding them to the router system. The router system, in turn,looks up the corresponding URL or URL list for each CID. Then, therouter executes a rule governing which CID or CIDs have priority andreturns a subset of the URLs associated with the CIDs with priority.Alternatively, the router refrains from prioritizing the requests andreturns all URLs associated with each content ID to a client readerprogram in the consumer's device. The client program either displays aweb page with hyperlinks to each URL, or it executes rules to selectwhich URL or set of URLs has priority, and then re-directs (e.g., sendsa metadata request) to the URL with the highest priority.

A single CID may be associated with metadata responses from severaldifferent participants (search engine provider, metadata aggregator,distributor like iTunes, Record Label, advertiser, etc.). In this case,the registrant of the CID specifies the URL or URL list corresponding toeach of the metadata responses for that CID. In addition, the registrantspecifies a rule governing the conditions in which the differentmetadata responses are triggered. The registration process isfacilitated by a graphical user interface accessible via a network, suchas a web interface enabling the registrant to list for each metadataresponse:

1. the URL or set of URLs for the desired metadata response;

2. the conditions that cause the routing system to select the metadataresponse.

The conditions are a function of the attributes of the routingtransaction. These attributes fall into two categories: user attributesand non-user attributes. The user attributes are obtained by the routerthrough the user registration process, in data provided in the metadatarequest, and/or in data derived by the router based on history ofrequests from the user. The user can specify metadata preferencesthrough registration or in the metadata request. Preferences can includelikes/dislikes about content genres, likes/dislikes for product/serviceadvertising, preferences in content format, preferences for types ofmedia players and media player settings, device capabilities, etc.Non-user attributes include attributes about the transaction derived bythe system, such as the time, geographic territory, history oftransactions relating to the content object or content objects in thesame genre as the content object, type of object, etc. For example, therouter's usage data provides information about the popularity of thecontent object, correlation to the preferences of others who haverequested metadata for the object, etc. In some applications, the readerpackages information about the object along with the extracted contentID, such as the object type and format. This enables the metadataresponse to be tailored to the object type and format that the user hasthe capability to render on his or her device.

A typical rule registration interface enables the registrant to selectdifferent URLs depending on the attributes of the routing transaction.For example, rule 1 dictates: use URL 1 when artist preference=TRUE;Account status=active subscriber; and Advertising Tolerance=LOW.

Rule processors can be implemented within and executed within one ormore different locations along the metadata request and response paths.Before enumerating these locations, let's review a summary of thelocations in a CMDS embodiment. The first location is the requestingclient, which is within the consumer domain shown in FIG. 9. The next isthe router system, which itself, has different components that cancontribute to rule processing. For simplicity, FIG. 9 shows the ruleprocessor as a single block, yet the rules processing function may bedistributed. The next location along the path is either back to therequesting client, or to metadata source to which the request has beenre-directed by the router.

At content identification and metadata request, rules are executed tocontrol:

1. what type of CID the client extracts (is client going to triggerfingerprint based CID retrieval, DWM CID retrieval or header/footer CIDretrieval?)

2. what client sends to the router (one or multiple CIDs)

At the router, the rules processor executes a rule or rules to control:

1. Which CIDs, if multiple CIDs for one content object are provided, haspriority?

2. Which URLs the router returns to client (e.g., single/multiple URLper each CID, or does one CID dominate?)

3. Whether the registrant of a content object has requested that therequest be re-directed to a URL of a device it controls, which in turn,provides a metadata response to the client.

At the client, upon response from the router or other device per above,the rules are executed to control:

1. what client displays (are URLs prioritized or not?)

2. what client sends to web server in response to packet returned byrouter.

At the client, a client program used to consume or manage content isequipped with a reader for one or a few types of content IDs. Thisclient controls what IDs get sent to the router and thus, controls whichentities are linked to.

Alternatively, there are multiple readers, each acting independentlyaccording to their own rules.

Alternatively, the router sends all URLs for metadata sources associatedwith corresponding CIDs back to the client and the client decides whichone to use. The client may also determine what type of context data itprovides to the metadata source, such as GPS information, depending onwhether the user wants to get or has paid for location based services.

To respect user privacy, user preferences can be maintained solely atthe client. The client maintains control over whether and when the userpreferences and attributes are forwarded to the router and/or metadatasource/repository. In some cases, they are not provided at all, and theclient aggregates and then tailors the metadata response from multipleURLs based on user preferences. In other cases, the client forwards thepreferences to the metadata source directly after receiving its URL tothe router. In this case, the router does not get access to the userpreferences.

At the router, the router determines based on context or otherinformation from the client how to re-direct the client to a metadatasource located at a URL.

The metadata source at the URL sends different types of metadata orlinks to a requesting client, which enables the client to pick or theuser to pick from among metadata/links presented in a user interface ofthe client.

As noted above, the metadata responses may be prioritized based on userpreferences. In such embodiment, the client is programmed to get orlearn user preferences and prioritizes links to metadata returned by thesystem accordingly.

In another embodiment, the router system provides additional servicesfor managing users, including, for example, authenticating users andmanaging user accounts. This can be explicit management of informationsupplied by the user, or management of user transactions based onconsent provided by the user. In either case, the router derives a userclassification based on information it has gathered about the user'spreferences for consuming content. In one embodiment, the router systemclassifies routing transactions based on the user's willingness to payfor products and services. Those willing to pay for premium content geta metadata response with opportunities to access this premium content,while those not willing to pay get no fee metadata responses that aresubsidized by advertising, for example. Further, if the router hasauthenticated the user and the user's account status, it re-directs theuser to URLs that are secure electronic commerce sites, initializedbased on the user's identity. This enables the routing system to linkthe user directly to electronic transactions without requiring themetadata source to handle the authentication processing.

One particular example of the authentication service in the router is toenable direct linking into a Digital Rights Management (DRM) server orother e-commerce server, in a state where the client ispre-authenticated. The client and router provide authenticationinformation needed to complete an electronic purchase through privateand/or encrypted data fields, or a combination of public and privatefields, where private only readable by certain entities.

Another service of the router is track the flow of content objectsharing over networks. Digital certificates, or other identifyinginformation of users, are used to detect different users that requestmetadata for a particular content object, which is uniquely identifiedvia content identifier. This tracking of content object flow by contentID and user certificates provides data to the content owner regardinghow content objects flow through networks of users. This providesanother means to identify an affinity group for content and tailorcontent and metadata distribution to the preferences of the affinitygroup. This tracing method traces content objects as they are processedby new and different users. Each time a request for metadata isreceived, the router logs the request and also records useridentification for the request, if available. The router analyzes thislog to identify the path of the content object through new users.

As demonstrated in the example above, the router enables metadataresponses to be governed by a hierarchy of rules distributed across thesystem, including macro rules implemented in the router that specifyURLs to return, and micro rules implemented in the client that furthercontrol how the client presents and links to these URLs.

Examples of micro rules include: rules governing how authentication of auser occurs to enable access to different type of metadata sources,(e.g., use of identity triangle—what user knows—password, has—accesstoken, ID card, and is: biometric login and user verification). Thelevel of authentication dictates the nature of the metadata provided(what links, metadata, etc. are provided). The level of authenticationalso dictates purchase limits and usage rights (rights forredistribution or sharing with other users).

An additional service of the router system is the support for handlingprivate and public fields in the data packets sent as metadata requeststo the router. For example, the client device in the consumer domainsends public and private fields (public field is generally readable,private field is packaged by client and likely encrypted, intended to beread only by authorized service, such as secure transaction server thatthe router links to). The router uses the public field, for example, asdata input for rules determining the URLs for the metadata responses.The metadata sources decrypt and use the data in the private fields toprovide tailored information to the user, while keeping the user'sinformation private and secure.

The rules in some systems also govern the amount of network resourcesallocated for a metadata transaction. In particular, the size of thesocket, data pipe or channel opened between the metadata source and theclient is a function of client's authentication level and user accountstatus (e.g., indicating willingness and ability to pay).

There are a number of ways to propagate rules through the networkinfrastructure. In one embodiment, rules are pushed to client throughcontent auxiliary channels in the content objects (such as fileheader/footer, encryption container, digital watermark, etc.)

In another embodiment, rules are distributed with media consumptionprograms, such as media players, like Windows Media from MicrosoftCorporation and iTunes from Apple Computer, etc.

Each component (client, router, and metadata source) executes its ownset of rules established based on what it has learned about the user.

As noted above, the input to the rules includes user and non-userattributes, including, but not limited to user demographics, deviceplatform, age, geography (GPS), time, search engine metrics thatprioritize results for content searches based on the user's searchhistory, which indicates preferences for types of content.

The input to the rules includes preferences derived from user behavior,content consumption history, most frequently accessed content, etc.

Another input includes content type, which enables the content to bytargeted at content type preferences of the user or the user's renderingequipment. Also, the rules specify different metadata responses based onwhether the client device is operating in on line or off line mode.Offline mode instructs the client to re-direct a metadata request to ametadata source in its cache of metadata, which serves as a localmetadata repository.

The router system provides a number of opportunities for revenuegenerating data services. One such service is revenue sharing model inwhich fees collected for distributing metadata are shared with contentowners as a function of usage data. In an embodiment of this service,the router tracks usage data corresponding to metadata requests forcontent objects and the usage data for these content objects is used todetermine revenue sharing among content owners and distributors. Therouter tracks usage data and this usage data is used to determine howartists that created the content get a share of fee collected under alicense in which collected fees distributed to the artists based onmetrics dependent on the distribution of metadata requests for thecontent objects. Additional models of revenue sharing are fee based,where a portion of the fees paid by consumers for metadata responses aredistributed to the content owners.

Another service of the router is an auditing function. One such audit ischecking the validity of URLs supplied to it during registration. Therouter periodically checks URLs in its database to make sure they arecurrent, valid, responsive, etc. The router also provides metadatarequest trend analysis that enables the metadata sources to anticipatemetadata request work load and allocate more resources to serve metadatabased on the anticipated workload.

The router itself is distributed and has instances of itself that aremirrored across the network. The router specifies to the clients whichamong several URLs to use for subsequent request for routing services.

Another service of the router is to track the form of contentidentification used to identify the content object for each transaction.This enables the router to flag content for subsequent content labeling,including layers of different content IDs. For example, a content objectidentified using a fingerprint is flagged for embedding a digitalwatermark. The digital watermark provides a finer grain identificationthan the fingerprint by differentiating among copies of the samecontent. The content ID in the watermark is then registered andassociated with metadata responses that are tailored to a particularcopy of the content object.

More on User Generated Metadata and Rules

Above, we described how to incorporate user generated metadata into themetadata routing system. The routing system has the flexibility toincorporate its own metadata repository for user created metadata, tolink to user generated metadata repositories maintained by others, andto integrate a combination of both types of metadata sources. Byestablishing an interface that allows metadata providers to registerlinks between content and metadata sources, the routing system has theflexibility to integrate different metadata sources into one unifiedmetadata service. For example, the routing system maintains linksbetween the identifier (or identifiers) for a piece of content (e.g.,song, TV or radio program, movie, Podcast, advertisement, etc.) andsources of metadata, including user generated metadata within or outsidethe routing system's domain. The database, in particular, stores theunique identifier of the piece of content and associated URLs of theuser generated metadata for that piece of content.

In particular, the routing system can specifically link to the usergenerated metadata maintained in different user generated metadata siteson the Internet. Examples of web sites that have implemented systems foruser generated metadata include Flickr and Del.icio.us, which provideweb services operated by Yahoo. These systems enable users to applymetadata, called “tags,” to pieces of content. In particular, Flickrallows users to upload images and add tags to images within the contextof the Fickr system. However, the tags are not persistently linked tocontent, and therefore, as content moves outside the bounds of theFlickr system (e.g., the Flickr servers or connected client device), thetags are easily lost. The routing system provides a means forpersistently maintaining links between a content object and itsmetadata, even as the object is distributed across different domains,devices and networks. Further, it allows a content object to bepersistently linked to several different user generated metadata sites.

When these capabilities of persistent linking across different sourcesof metadata are combined with rules based processing, the systemfulfills a more sophisticated array of metadata requests across a broadarray of metadata sources. Each piece of content becomes its own node orportal interconnected with disparate sources of metadata acrossheterogeneous distribution methods, networks, content formats, anddevices. In addition, rules processing in the system filters metadataaccording to user preferences.

It is anticipated that in many applications, users will preferuser-community generated metadata over the original metadata from thecontent owner or distributor. An example is user generated metadata thatassigns content ratings to content for parental control. In particular,a user may trust the content rating applied by the trusted community ofwhich he or she is a member over the rating applied by an industrygroup. Today, as long as the user stays within the domain of a providerof trusted content (e.g., within a connected session to a web service),the user can take advantage of the metadata associated with the contentin that domain. However, when content travels outside the domain (e.g.,is stored in a device that does not respect or even understand theprotocol or metadata from the domain, goes offline, is trans-coded orplayed, is emailed to a friend), then a scheme is needed to re-associatemetadata and apply the user's preferences. The routing system supportsthis re-association and enforcement of user preferences by allowing theuser to request metadata with the user's rules that specify that, incertain contexts, the content rating in the metadata from the user groupis to be used instead of the industry content rating.

A typical usage scenario of the system to apply ratings is as follows:user encounters an content (in any of a myriad of ways: e.g., receivesfrom a friend, downloads from a social networking site, records from alive broadcast, searches an archive); the user's device includes anapplication that incorporates the reader, which extracts a content IDfrom the content (or alternatively, the user selects the content, whichtriggers transmission of it to a remote reader that does the same); thereader forwards the content ID along with user preferences to therouting system, the routing system extracts the related metadata fromlinked sites specified by the associated URLs, the routing systemapplies the rules applicable to the content, including those based onuser preferences, and sends back a metadata response to the user thatinforms the user of the rating and/or the reader automatically enforcesthe rating by controlling play out of the content.

These metadata sources, as noted, can be dynamic metadata sources basedon dynamically generated metadata from searches, RSS feeds, andmash-ups. The URLs identify more than just IP addresses of physicaldevices, and extend to dynamic metadata sources in virtual environmentssuch as Second Like (URL in protocol for Second Life adheres to SLTPprotocol).

Federated Content Identity

The concept of federated identity has emerged in response to demands fora user-friendly and interoperable frame work for establishing useridentity across disparate domains (e.g., across the security wallserected around different entities' databases, such as the metadataservices of a content distributor, content owner, social networkingsite, metadata tagging sites like Flickr and del.icio.us). Simply statedfrom the user perspective, “federated identity” is an identitymanagement framework that enables the user to access disparate dataservices, each with their unique secure log in procedures, with a singlelog in. As described below, embodiments of the routing system leveragefederated identify technologies, such as SAML and WS-Trust, to establishand enforce user identity for users of the routing system, includingboth providers and consumers of metadata.

The disparity of content identification and metadata protocols creates asimilar demand for a scheme of federated content identity. The routingsystem satisfies demand by creating a framework that unifies disparatecontent identification technologies (such as digital watermarking,content fingerprinting, headers in files whether un-encrypted or part ofan encryption container) as well as incompatible protocols for contentidentifiers. Further, it unifies disparate sources of metadata, as wellas different metadata formats. In short, it provides cross-platformcontent identity and metadata services. A typical usage example toleverage these capabilities is as follows: a user wishes to find allmetadata relating to a particular concert tour associated with aparticular song; the user submits the user preference “concert tour” and“year=2005”) for the song; the reader extracts one or more contentidentifiers from the song, packages them with the user preferences, andsends a request to the routing system; the routing system establishes afederated content identity for the song knowing the ID providers fromthe reader and the content IDs; the routing system uses this contentidentity to find linked sources of metadata in its database (e.g., getsthe URLs of these metadata sources); the routing system aggregates themetadata responses from these URLs from different domains; the routingsystem applies the user's preferences and returns a metadata responsesthat relate to concert tour and the year 2005 to the user. The user neednot concern herself with the details of identifying the content orgaining access to disparate metadata sources.

Public Interfaces for the Metadata System, Mash Ups for Metadata andMetadata Usage Statistics

The routing system establishes an interoperable system for associatingcontent with metadata across disparate content identification andmetadata systems. In so doing, it also provides a mechanism formonitoring consumption of content and metadata across disparate domainsof content origin and consumption. The support for user generatedmetadata further enables new sources of metadata which users will likelyvalue as much or more than the content itself. This is particularly truefor a system that analyzes metadata usage and content usage and makesinformation available as additional metadata linked to the contentbecause it facilitates the user's ability to search for content that isof particular interest to him. One of the must compelling types ofmetadata is the metadata that identifies content by its popularitywithin certain groups (e.g., popularity as defined by tastemakers,affinity groups, niche genres for content, etc.).

In view of this important function of identifying compelling metadata,there is a commensurate value in an interface that efficiently unlocksthis value by establishing programmatic access to the metadata andmetadata statistics. Within a single system for metadata generation,programmatic interfaces are provided for that particular system.However, an embodiment of the routing system described in this documentprovides a programmatic interface across heterogeneous contentidentification technologies and metadata sources, and further, providesa programmatic interface to the metadata usage data that is collectedacross these heterogeneous metadata sources and linked back toindividual content items through a variety of content identificationtechnologies.

Examples of programmable interface technology that the routing systemleverages include mash-ups built on Web 2.0, Programmable web, andsemantic web programming constructs and Application ProgrammingInterfaces (APIs). The implementer can use these technologies to buildthe metadata response aggregator, traffic monitor, and rule processordetailed above, as well as to build their own versions of these moduleson top of the routing system. For example, the system can be embodied ina hierarchy of mash-ups, each providing additional functionality on topof the APIs of other mash-ups of metadata services provided by thesystem. The routing system, by providing a mechanism of linking metadatasources to content identifiers, creates a Content Object

Name Service (think of it as a Domain Name Service for content items).Further, the response aggregator, rule process or and traffic monitorbuild on top of this service, which as noted, can each be implemented asmash-ups of the routing system. When these metadata services areconstructed in this form of interconnected mash-ups, the routing systemprovides a form of DNS for content metadata mash-ups.

Measuring Metadata Popularity and Tastemaker Identification

The tracking of content and metadata consumption in the system andsubsequent publishing of this data to the user community enables user'sto more effectively identify metadata that matches there preferences. Italso provides an opportunity for content owners to analyze thesepreferences and re-package content with popular user generated metadata.Content owners can also identify unique affinity groups and tailor newreleases to the preferences of these groups. As noted above, the systemtracks several forms of usage data. These types of usage data includemonitoring traffic of content objects (e.g., tracking objectdistribution), traffic of metadata requests (e.g., number of requestsfor particular metadata, or metadata from a particular source), and userpreferences and rules processing (e.g., user preferences derived frommetadata analysis, such as the affinity group analysis). With thesupport for dynamic metadata (metadata generated over time as an objectis consumed) and the means to measure popularity of metadata and itsproviders, the system identifies high value metadata which provides anopportunity for content object owners and advertisers to package thispopular metadata and monetize it (sell it or sell advertising presentedwith its consumption by users).

The system also is able to capture a historical archive of metadatageneration and consumption data, which further allows content andmetadata distribution to be analyzed to identify transient metadatacaptured from points in time to be packaged and monetized in a similarfashion. For example, dynamic metadata can be packaged with the contentobjects that caused its generation and distributed. Examples in includecontent packaged by tastes of an affinity group of users, a period oftime, a geographic market, etc.

CMDS Example Implementation Summary

The Content Metadata Directory Services (CMDS) provides a global trusteddirectory service that connects consumers of identified content tocontent-provider authorized and managed metadata databases and otherdigital resources.

It solves the problems created by the fact that digital distributionseparates content from packaging, new 1-1 marketing opportunities arenot being optimally utilized for content distribution, and digitaldistribution is moving forward with proprietary channels that make thevalue chain more complex rather than simpler. The CMDS system providesall existing value chain participants an environment to agree uponmetadata usage and manage their proprietary metadata, as opposed tobeing another proprietary metadata repository. It also providescross-sell/up-sell e-commerce opportunities. The CMDS system isinteroperable with all content identifiers, PC and mobile devices, andenables usage reporting with vital marketing statistics.

The CMDS system standardizes three components (1) RegistrationInterface, (2) Resolution Interface and (3) Router Requirements. Theinterfaces are specified in terms of XML-based Web Services, an existingindustry standard, for simplicity and interoperability. The routerrequirements guarantee that the system functions properly and maximizesvalue to vendors and users. These minimal specs create a system that issimple for vendors and users to interact with, while providing extremelyflexible workflow and architecture. For example, CMDS can either (1)create unique content identifiers (CIDs) that can be embedded with anytechnology, such as digital watermarks (DWM) or signed headers, or (2)utilize CIDs created by pre-existing systems such as contentfingerprints (a.k.a. robust hashes), Electronic Product Codes (EPC),IFPI's Grid, and URI. Furthermore, users can learn more about artists,similar content and related items, and purchase content and relateditems.

The CMDS system provides users with valuable information and simplepurchase options, and helps content owners and retailers increase ROI byexpanding their knowledge of content usage and making it easier forconsumers to buy content and related items.

CMDS Implementation Definitions

The terms used in the following sections are defined here, inalphabetical order.

Term Description Central Database A global, master Database (whereDatabase defined below). Central Handler A global, master Handler (whereHandler is defined below). Central Router A global, master Router (whereRouter is defined below). Content ID (CID) A unique content identifier.It is different for different pieces of content, and can be unique fordifferent copies of the same content. The combination of the CID with IDProvider ID and ID Version is globally unique. These additional fieldsallow ID Providers to embed and detect a smaller namespace (i.e. fewerbits) and the system to work with all pre-existing ID systems. However,these additional fields also require slightly more complexity in theRouter. Content Metadata A system for Content Providers to registerContent IDs and URLs, and Users to Directory Services resolve ContentIDs into URLs to obtain more information about the content (CMDS) wherethe Content Providers manage their proprietary metadata. ContentProvider The provider of the content, such as the content owner andretailer, or any company with rights to distribute content and/orcontent metadata. Database The second component of a Router which isused to store the Content Provider's links to their proprietarymetadata, and store vendors or users' contact information. Note: Oftenthe term is used in the plural because it can refer to several linkeddatabases. Digital Watermark Data embedded within the content that doesnot degrade the content's quality (DWM) to end-users, but is reliablydetectable by enabled hardware or software. EPC Electronic Product Codeas specified by EPCGlobal. Fingerprint A fingerprint identifies contentfrom features of the content. It is also known as a robust hash orcontent based identification (and should not be confused with a forensicDWM). Handler The first component of a Router which handles theregistration or resolution requests and responses. Note: Often the termis used in the plural because it can refer to several linked handlers.ID Provider The company that provides the technology to identify thecontent and interface with a Router. ID Provider ID The unique IDassigned to the ID Provider. An ID rather than name is used so that thecombination of ID Provider ID, ID Version and CID is a globally uniquenumber (when the CID is a number, such as when created by this system),and numbers are faster to lookup in a Database. (If the CID ispre-existing, such as URI, it may be formatted as text.) ID Version TheID version provides the version of the CID algorithm. It enables the IDProvider to re-use the same IDs in different version of theiralgorithms, such as for different content types, as well as to usevarious ID formats. The ID Version is different for each algorithm thatuses overlapping CIDs for an ID Provider. Mirror Database An exactduplicate of the Central Database. Mirror Handler An exact duplicate ofthe Central Handler. Mirror Router An exact duplicate of the CentralRouter. Resolution Request The interface defining the message sent to aRouter to request URLs (or other Message information). Resolution Theinterface defining the message sent from a Router in response to aResponse Message resolution request. Registration The manager of theCMDS system. For a public system, as used in B2C Authority environments,the Registration Authority is a trusted 3^(rd) party vendor. There isone public Registration Authority. For a private system, as used in B2Benvironments, the Registration Authority is usually the private systemprovider. There may be numerous private Registration Authorities.Registration The interface defining the message sent to a Router torequest registration of Request Message CIDs, URLs, vendors or users.Registration The interface defining the message sent from a Router inresponse to a Response Message registration request. Request Code A keypart of the registration or resolution request message that describesthe desired action for the message. Router The backend system thathandles registration and resolution. It includes two main components, aHandler and Database. Note: Often the term is used in the plural becauseit can refer to several linked routers. User The end user of the system.For example, it may be a consumer linking to more information via theirPC Multimedia jukebox, or a movie critic linking to current marketingmaterials via a closed, private system.

CMDS Background

The Content Metadata Directory Services (CMDS) system is needed sincecontent identification technology cannot provide useful informationwithout accessing a backend system that links the ID to relevantinformation (a.k.a. metadata). It is a router-based system, which isbeneficial to a central metadata repository, so that content providerscan manage their proprietary information and content can be routed tothis information from any location.

CMDS provides a global trusted metadata directory service that connectsconsumers of identified content with authenticated “origin of source”databases and other content-provider authorized digital resources.

CMDS enables content owners to:

-   -   Leverage in-house digital asset management system    -   Gain from economies of scale    -   Act as the content authority over their own digital assets; and    -   Address digital distribution issues from a single, unified        approach, rather than a fragmented approach.    -   Cross-sell/up-sell

CMDS also provides consumers metadata and e-commerce opportunities

-   -   Focused on routing        -   Content Providers manage their proprietary information    -   Enable eCommerce for all value chain participants        -   e.g. Both content owners and retailers can embed CIDs    -   Interoperability with all content identity provider technology    -   Compatible with both PC and mobile devices    -   Interoperability for multiple ID Providers whom license a common        algorithm    -   Enable usage reporting and vital marketing statistics

CMDS System Embodiment Overview

A content identification system has five main components: registration,embedding/calculating, reading, resolution, and a router, as shown inFIG. 4. These components can be grouped into content identification andcontent routing (e.g., CMDS) categories. The content identificationcomponents include embedding content identification (or calculating itfor fingerprinting) and reading content identification (a.k.a.detection). The content owner usually handles the embedding and theconsumer product usually handles the reading.

The CMDS components include:

-   -   1. Registration Interface    -   2. Resolution Interface    -   3. A Router

These three components are standardized in the companion specificationsuch that any content identification technology can interoperate. Theexample implementation is also optimized for both technologies, such asDWM, where the fewer bits in the identifier the better, and fortechnologies, such as URI, which have non-integer namespaces. Theexample implementation has the flexibility to be optimized for a PC ormobile environment (or any future hybrid environment).

In FIG. 4, the content is labeled Protected and Identified Content sinceit is identified when distributed due to this process, and may also beprotected by other means. Although the focus of this exampleimplementation is using identification to enhance content, theidentification may also be used for protecting the content and/or othertechnology may be used to protect the content. When the identificationis used to both enhance and protect the content, there are mutualbenefits, such as pirated content that doesn't have the identificationdoes not provide the enhance features to the user. In other words, thisimplementation is not a replacement for content protection, butsynergistic with it.

A Registration Authority handles these three content routing components.For a public system, as used in B2C environments, the RegistrationAuthority is a trusted 3^(rd) party vendor. There is one publicRegistration Authority. For a private system, as used in B2Benvironments, the Registration Authority is usually the private systemprovider (and usually the only ID Provider). There may be numerousprivate Registration Authorities, and each system most likely interactwith another system in this B2B environment.

This system's design allows the Content Providers (including contentowners, such as Record Labels, Movie Studios and Stock Photo Agencies,and retailers, such as Apple iTunes, Napster, WalMart, Hollywood Video,etc.) to interact directly with the user, such as a consumer, as shownin FIG. 5. This enables the Content Providers to manage their ownproprietary data. In other words, the usage model is the user interactswith a router, which redirects the user to the Content Provider formetadata and e-commerce opportunities.

Thus, the system routes requests for metadata to Content Providers, suchas content owners and retailers. In other words, the Router includes aDatabase that mainly contains CIDs and URLs that link to metadata ande-commerce opportunities, which are stored by the Content Provider, notat the Router.

The system has a distributed architecture, as shown in FIG. 7. At thistime, only the duplicates of the Central Router (labeled Mirror Routers)are specified. These Routers can have separate Registration andResolution Routers. There will most likely be more Resolution Routerssince there will be more resolution requests. In the future,

Cached Routers will interact with the Mirror Resolution Routers and onlysave recent resolution requests for efficient responses. Cached Routersare not applicable to registration requests since these requests occurneither often nor repetitively and are immediately forwarded to theCentral Router. The example implementation requires the reader toperiodically request the address of the Router that it should beutilizing for registration and resolution; thus, the system candynamically change configuration. It is unnecessary for the CentralRouter and Mirror Routers to request addresses, as they are all run bythe Registration Authority and, thus, know each other's addresses.

A Router consists of a Handler and Database. A Handler accepts theregistration and resolution requests, quickly obtains the requiredinformation and sends the registration and resolution responses. It maybe a single software thread running on the same machine as the database,such as for a local low-quantity implementation, or it may quicklyhand-off requests by request code or ID Provider (as both fields are inthe XML message header) to various request handlers that are linked to alocal request Databases across multiple CPUs, as shown in FIG. 6.

Workflow Example

An exemplar workflow demonstrating content owners and retailerregistering contact information and content, and consumers linking tometadata and purchasing content is shown in Table 1. The example assumesthat the ID Provider and two Content Providers, a content owner andretailer, have received their respective identification and passwordsfrom the Registration Authority. It also assumes that ID Providers haveregistered contact information (via UpdateIDProvider request code), anddistributed embedder and reader software. The request codes are shown initalics between the arrows for messages sent to the router.

Architecture Example

The architecture is flexible since the specification defines anextensible messaging interface and router design.

An example architecture which enables both content owners and retailersto use the system is shown in FIG. 8. Many other architectures orexpansion of this architecture are possible, but this architecture isexpected to be the most used architecture. This architecture enables theworkflow discussed in the previous section, as well as many otherworkflows. The architecture includes:

-   -   Content owner environment with embedding/calculating software        that has a registration interface to embed identification in the        content (or store its fingerprint)    -   Retailer environment with embedding/calculating software that        has a registration interface to embed or add identification to        the content (or store its fingerprint)    -   A Router consisting of a Central Handler, Central Database,        Mirror Handlers and Mirror Databases    -   Protected and identified content in cyberspace    -   User Environment with reader software that has a resolution        interface to link the user to more information, as well as a        registration interface to register the user, if the user opts-in        to send secondary personal information

Usage Scenario Examples

These usage scenarios help demonstrate the flexibility and capabilitiesof the specification. They also discuss what technically happens in thebackground (with request codes and other XML tags in parenthesis)—all initalics since they are technical details.

Consumer Linked to Metadata and eCommerce

This usage scenario includes most aspects of registrations for IDProviders, Content Providers, e.g. content owners and retailers, andUsers, as well as Users, e.g. consumers, linking to metadata andeCommerce. It demonstrates several key aspects of the system, and ismost similar to the workflow example in Table 1.

ID Provider Registration

The first step is registration of at least one ID provider. The IDprovider receives an ID and password from the Registration Authority viaa secured process, such as a mailed letter or telephone call and companyand contact person security check. Next, the ID provider securelyregisters their contact information with the registration authority,either through the Registration Authority's software (viaUpdateIDProvider) or through an interactive secure web page. The IDProvider is notified of success or any errors.

In the background, the ID Provider embedder and detector softwarecontains the ID Provider ID, and submits it, along with an ID Version ofthe embedding or detection algorithm, with every request.

Content Owner Registers as Content Provider

The second step is registration of a content owner. The content ownerreceives a Content Provider name and password from the RegistrationAuthority via a secured process, such as a mailed letter or telephonecall and company and contact person security check. Then, the contentowner uses their embedder or related software received from the IDProvider to securely register contact information (viaUpdateContentProvider). The embedder software verifies the response, andnotifies the content owner of success or any errors.

Alternatively, the content provider could have used the RegistrationAuthorities secure web site to interactively register their contactinformation.

Content Owner Registers New Content

Once the Content Owner has registered, they securely register theircontent. First, they use the embedder or related software to obtain aunique Content ID (via CreateCID). Afterwards, the Content Providerregisters two primary URLs, one for PCs and one for mobile devices (viaURLType XML tag with Full or WAP data entry), as well as four additionalURLs, two for PC and two for mobile, (via six calls with RegURL requestcode). For example, for both PCs and mobile devices, the primary URLprovide static information about the movie Fantasia from Disney, oneadditional URL provides information about songs in Fantasia, and theother additional URL provides items for sale regarding Fantasia fromAmazon.com, using a dynamic web page via a URL including search termsbased upon the CID. The software application verifies the response forsuccess and let the content owner know about the success (or anyerrors).

In one alternative, the content owner could enter multiple URLs in thesoftware's GUI with checkboxes for fully functional or WAP. In thebackground of this configuration, the software uses the request groupingmethod to obtain the CID (via CreateCID), register the primary URLs (viatwo calls with RegURL), and additional URLs (via two calls withRegURLs). The Routers handle the timing such that the CID is registeredbefore the URLs.

In another alternative, the content owner can use the RegistrationAuthorities secure web site, and interactively register the URLs,one-by-one.

Retailer Registers as Content Provider and Registers Content

A retailer, assuming they have worked out rights with the content owner,can also securely register as a Content Provider with the RegistrationAuthority, obtain a Content Provider name and password, and registercontact information (via UpdateContentProvider). For example, theretailer could be Apple iTunes store. Then, when the retailer preparesto sell content, they request a CID (via CreateCID) and add two URLs,one primary URL to sell songs by the same artist (via RegURL), and oneadditional URL to sell similar songs (via RegURLs).

Anonymous User Linking

When a user receives a copy of the content with the registered CIDs, theuser can request and receive more information from their multimediaplayer. Preferably, the multimedia player includes a reader plug-in thatalways scans for CIDs, checks that URLs are registered for this CID, anddisplays a symbol or “more info by <company name>” icon to let the userknow that the content is enhanced. This scanning process also makes theresponse time immediate since CID detection has already been performed.

When the user selects to receive more information, the user receivesfive web links with brief descriptions. There are three links from thecontent owner: one with the film history, one with related songinformation, one with items for sale regarding Fantasia from Amazon.com.There are two links from the retailer whom sold them the movie: onewhere they can buy songs by the same artist, and one where they canpurchase similar content. The user can click on the links to visit thedisplayed web sites.

In the background, the reader software requests the URLs (via ResURLs)with a group containing two requests, one for the content owner's CIDand one for the retailer's CID. As the last step, the reader softwareparsed the returned URLs and displayed them to the user.

If the CIDs are embedded by two different ID Provider technologies, theuser will see two different “more info” buttons, e.g. one “more infofrom Disney” and one “more info from Apple iTunes Store” and thedepending upon the user's selection, the corresponding request is sentand response is displayed.

Mobile User

When a cell phone user identifies content, he/she links to the WAP orWMI version of the registered URLs, assuming the Content Providerregistered such URL types (via XML Tag URLType with WAP or WMI dataduring registration or resolution). Information, formatted for theirsmall screen, is displayed. In addition, preferably, the user can selectthe display of only a primary link (for content owner or retailer) sothat the Content Provider's information is displayed immediately afterselecting to receive more information (without the user having to selectagain from a list of URLs and descriptions since they may be driving).

For example, when the cell phone user hears a song that they like on theradio, they can identify the song (via a DWM or fingerprint) and link tomore information. Similarly, the mobile user can identify songs they arelistening to on their PDA phone and link to more information.

User Registration

Another user decides to register personal information to obtain a chanceto win a new hybrid car. They register from the reader plug-in for theirmultimedia player (via RegUser). The software application verifies theresponse for success and lets the user know about the success (or anyerrors). The user can update their information at any time (via UpdateUser), or decide to opt-out for one specific link or all future links.

Registered User Linking

When this registered user requests more information about the video fromthe reader plug-in software (via ResURLs), the same five links asdisplayed for the anonymous user are displayed, as well as links toadditional theatres in the user's zip code that are playing Fantasia orsimilar movies, as well as stores in the user's zip code that carry therelated merchandise. In addition, if the Content Provider (e.g. contentowner or retailer) maintain information for each username, they cansuggest other items based upon the user's previous purchases, or producea “instant chat” icon if this is a preferred customer who has purchasesseveral things in the past (equivalent to nicely dressed shopper orfrequent shopper card holders getting better service in the physicalstore). Someday this user believes they will be one-click away frompurchasing any of the listed items, when all stores share the samesecure user information.

Content Provider and ID Provider Reports and Billing

At the end of the month (or any other time), the Content Provider (e.g.content owner or retailer) logs onto the Registration Authorities webpage and securely views usage data for each of their registered CIDs.They see that their new movie is hot in the northeast part of the USAand Canada, especially by 8-to-10 year olds around 7 PM EST. They alsosee that its usage has been starting to decline, and represents 20% oftheir current resolution usage for this age group, indicating that it istime to release a new movie with this target audience. Finally, they cansee their costs and billing options, such as automatic withdrawal atfixed amounts or monthly billing.

The ID Provider can also log onto the same web site and view aggregateusage data for all of the CIDs registered using their technology.However, they cannot view stats by individual CIDs since that is ownedby the Content Provider.

In the background, each Router is saving log files for each hit, and,preferably, daily processing the log files to aggregate usage data toprovide real-time interaction with these stats, as well as automaticcapabilities to email reports to the Content Provider and ID Provider.

Fingerprints/Robust Hashes Link Content to URLs

When using fingerprints to identify content, the fingerprint iscalculated from the content and entered into a database. Then, whentrying to identify content, the fingerprint is calculated, and matchedto the closest fingerprint in the database that also falls within acertain threshold of certainty. The fingerprint is usually a collectionof sub-fingerprints, especially when content is streaming. As such, thefingerprint is not a unique content ID, but the fingerprint databaselinks the fingerprint (i.e. collection of sub-fingerprints) to a uniquecontent ID.

Content Provider Registration

The Content Provider can either (i) utilize the fingerprint provider'sproprietary content ID system and register pre-existing CIDs with aRouter (via RegCID), or (ii) request a unique CID (via CreateCID) anduse it in the fingerprint database. Then, the Content Provider canregister URLs to link to the CID (via RegURL and RegURLs).

In case (i), CID uniqueness is guaranteed since the fingerprint databaseguarantees the CID is unique in that database, and the combination ofthe CID with ID Provider ID and ID Version guarantee global uniqueness.In case (ii), the CID is guaranteed to be unique by the Central Router,and the same combination is globally unique. The ID Version is uniquelydefined for each fingerprint algorithm and related database for each IDProvider.

Linking Users to Metadata with Fingerprints

The user selects to receive more information as with any CID andreceives URLs and short descriptions (via ResURLs). The user then clickson the URL with the information that he/she wants to receive.

In the background, when a user requests to receive more information forcontent identified with fingerprint, the fingerprint reader calculatesthe fingerprint, sends it to the fingerprint server (either running onthe fingerprint provider's server or on the Central Router), thefingerprint server determines the CID from the fingerprint database,returns the CID to the reader, and the reader uses the CID to requestthe URLs (via ResURLs) from the Router. The Router, having access to theIDProviderID, ID Version and CID data in the resolution request message,uses this globally unique combination to lookup the correct URLs. Theproper ID Version is known by the reader since it used that version ofthe algorithm to determine the CID.

Linking via Other ID Systems, such as EPC

In some cases, a different Registration Authority will have previouslyprovided a unique identity, possibly for other purposes, and it isoptimal to be able to use this unique content ID in this system. Forexample, the Electronic Product Code (EPC) provides unique IDs withradiofrequency identifiers (RFIDs). Similarly, IFPI's GRid providesunique content IDs. Or, 4C provides unique IDs with Verance's DWM.Furthermore, an ID Provider could generate their own unique ID, such asusing the “album:artist:song” combination from ID3 tags.

An example 96 bit EPC format, also known as general identifier (GID-96)is:

-   -   Header: 8 bits    -   Manufacturer: 28 bits or 268 million unique IDs    -   Product (SKU): 24 bits or 16 million unique IDs    -   Serial Number: 36 bits or 68 billion unique IDs

As the goal of CMDS is to link users' to information managed by contentowners and identified by multiple ID technology providers, whereas thegoal of EPCNet involves tracking items through the distribution processfor each participant, the backend structures are different. Thus, thesetwo networks can work synergistically, such as with the EPCNet IS havingan interface to a CMDS Router. An example of using EPC, such as a filmposter ad containing an RFID with EPC GID-96 format, is described below.

Register URLs for Pre-Existing CID

The first step is that the Content Provider registers the pre-existingCID (via RegCID). Then, the Content Provider registers a primary FullURL (viaRegURL), and, if desired, they can register additional URLs (viaRegURL or RegURLs) or URLs for mobile formats.

When using this specification to create CIDs, the CID namespace isguaranteed to be unique for each ID Provider and their current IDVersion (e.g. algorithm version), and the CID format is decimal.However, since the pre-identified content may have CIDs that overlapother CIDs used by the same ID Provider in this system, the ID Version(via IDVersion XML tag) is used to determine the proper CID namespace.For example, a CID representing a GID-96 EPC code has the hex format ofHH.MMMMMMM.PPPPPP.SSSSSSSSS where H is header (8 bits), M is Manufacture(28 bits or 268 million unique IDs), P is Product SKU (24 bits or 16million unique IDs) and S is Serial Number (36 bits or 68 billion uniqueIDs). Thus, the ID Provider has an ID Version for the EPC GID-96 format,and different ID Versions for other EPC formats or other CID formats(e.g. DWM). When the embedder registers an EPC GID-96 format CID, itsends the corresponding ID Version.

Link to URL with Pre-Existing CID

The reader software detects the pre-existing CID, sends it to the router(via ResURL), receives URLs and displays them to the user.

In the background, the router, having access to the IDProviderID, IDVersion and CID data, uses this globally unique combination to lookupthe correct URLs. The proper ID Version is known by the reader since itneeds to use that version of the algorithm to detect the CID.

Interoperable ID Technology from Multiple ID Providers

When one company licenses embedder and detector technology (i.e. OEM) tomultiple ID Providers, there arises the user-desired solution where oneID Provider's reader can utilize a CID embedded with another IDProvider's embedder. However, the ID Provider desires “credit” for theembedding process; thus, this content routing system tracks theembedding ID Provider.

ID Provider ID Embedded in Content

Each ID Provider's embedder embeds their ID Provider ID along with theCID that is requested and embedded by the Content Provider (viaCreateCID).

Embedding ID Provider ID Included with URL Requests

When the reader software reads a CID, it also reads the embedding IDProvider ID. If the embedding ID Provider ID is different than thatstored in the reader, it is included in the URL resolution requestmessage (via the EmbIDProviderID XML field). The Router logs theembedding ID Provider's ID for any further action, such as beingproperly compensated for the embedding process.

CMDS Section Conclusion

In conclusion, the companion specification provides valuable informationto consumers, and enables a distributed routing architecture such thatContent Providers manage their proprietary data and interaction with theconsumer. Content Providers can include content owners, such as RecordLabels, Movie Studios, stock photo agencies, etc., and retailers, suchas Apple iTunes, Walmart (clicks-and-mortar), catalog companies,advertisers, Netflicks, etc.

Furthermore, the specification enables Content Providers to use anyidentity provider technology to link users to the proper information. Inaddition, when multiple ID Providers are sharing a contentidentification OEM algorithm, every router can seamlessly interoperateand track usage for proper payments. Importantly, the system enablesmultiple CIDs to exist in content such that the complete value chain(e.g. content owners and retailers) can participate, or create businessrules for participation.

Furthermore, the specification is optimized for all identificationtechnologies and existing systems, including digital watermarks (DWM),fingerprints (a.k.a. robust hashes), Electronic Product Codes (EPC),IFPI's Grid, and URI. Finally, the specification includes logging, notonly for security tracing, but also for usage report that help IDProviders understand router demands and Content Providers understandcontent usage. The specification can easily be expanded to handle usagecases around seeding multiple ID systems and providing “buy now”functionality for non-legitimate content.

In the end, the specification should help content owners and retailers(thus distributors) increase sales (↑ROI) by expanding the knowledge ofcontent usage and making it easier for consumers to buy content andrelated items.

The following example implementation uses industry standard XML-basedWeb Service to provide an open interface to the Routers.

Overview of Example CMDS Implementation

The main components of the specification of this example CMDSimplementation include:

-   -   Registration Interface        -   Registration Request Messages        -   Registration Response Messages    -   Resolution Interface        -   Resolution Request Messages        -   Resolution Response Messages    -   Router Requirements

The registration and resolution request messages use XML and include:

-   -   Header    -   Body        -   Primary Information        -   Secondary Information

The response messages are simpler. The registration response message issimple, requiring no header or body sub-sections, and the resolutionresponse message only includes primary and secondary informationsub-sections.

ID Providers, Content Providers, and Users

To understand this example implementation, it is helpful to understandthe relationship between ID Providers, Content Providers and Users.

ID Providers:

Companies that provide the technology for content identification and tointerface with a Router.

Content Providers:

Providers of the content, such as the content owner and retailer, or anycompany with rights to distribute content and/or content metadata. Forexample, content owners can include Record Labels, Movie Studios, andStock Photo Agencies. Retailers can include Apple iTunes, Wal-Mart(click-and-mortar), advertisers, catalog companies, and Napster.

Users:

The end users of the system. For example, it may be a consumer linkingto more information via their PC Multimedia jukebox, or a movie criticlinking to current marketing materials via a closed, private system.

CID, ID Version, ID Provider ID and Globally Uniqueness

Furthermore, this example implementation is based upon a unique contentidentifier, labeled a CID. It is critical that CIDs are unique for eachID Provider ID and ID Version. CIDs can overlap for different IDProvider IDs or different ID Versions. ID Provider IDs are different foreach ID Provider, and an ID Provider could register multiple ID ProviderIDs, if determined as needed by the Registration Authority.

The ID Version is the version of the technology/algorithm that embedsand reads the CID. The ID Version is always known by the embedder andreader since they determine which algorithm to embed or read the CID.The ID Provider can have CIDs that overlap when they have different IDVersions, and uses different ID Version when CIDs can overlap.

For example, a video may have the same CID as a song, or one songembedded by ID Provider 1 may have the same CID as a different songembedded by ID Provider 2 (or by ID Provider 1 using a new ID Version).

As such, CIDs are not globally unique unless combined with these othervariables. Thus, the combination created by appending IDProviderID,IDVersion and CID together (e.g. appending<IDProviderID><IDVersion><CID>) is a globally unique ID, usually anumber.

Alternatively, the globally unique combination can be represented as aURI, formatted as “CMDS://<IDProviderID>.<IDVersion>.<CID>”.

The advantages to dividing the namespace in this format are twofold: (1)fewer bits are needed to represent CIDs since CIDs can be re-used in newcontent or new algorithm versions, and (2) the system is easier tointegrate with pre-existing identity systems such as EPC, fingerprintingand 4C/Verance DWM since the CIDs can overlap between these systems butbe differentiated with the ID Version.

Finally, for many identification technologies, the CID is an integer,and it is most efficient for transport and backend/router processing touse an integer field. However, for other identification technologies atext field is required, and the router can process the text into aunique content identifier. As such, the CID format is determined by IDVersion data, and properly handled by a Router. As an aside, two XMLschemas will be present for these requests, one for an integer CID andone for a text CID. If possible, it is optimal to use the integerformat. Along these lines, databases can be indexed by all threeidentifiers (IDProviderID, IDVersion and CID) as separate variables ordatabases, or one database can use this triplet ID as a globally uniqueindex when the CID is integer format.

Registration Interface Specification

The registration process enables the content provider to obtain uniqueCIDs and link the CID to URLs. It also enables the ID Provider, ContentProvider, and User to register contact information.

The registration works from both (i) an interactive human-readable webinterface and (ii) a web services interface that interacts directly withregistration software, such as a CID embedder (or multimedia plug-in foruser registration) that runs on the vendor's or user's computer.

Secure Authenticated Channels

The client web and software interface uses a secure authenticatedchannel with the Router. This protection is required so that no one butthe proper vendor can change the registration data.

Content Provider, ID Provider and User Registration

Content Providers and ID Providers initially register with theRegistration Authority via a process that verifies them and the contactperson to be a trusted provider. During this process, the ContentProvider is assigned a unique vendor-name and password, and the IDProvider is assigned a unique numeric ID and password.

ID Providers are assigned a unique number rather than name for thefollowing reasons: it is quicker for a Router to lookup a number, the IDProvider's software remembers the number (so the human readability isnot important for remembering the unique identification), and theglobally unique combination of IDProviderID, IDVersion, and CID is anumber.

Once they receive their vendor info and password, Content Providers andID Providers can update their contact information via their embeddersoftware or directly with Registration Authorities interactive web site.

Users register via the reader software, which registers a username andpassword, and should provide the user the option to store the passwordfor future usage. The reader software keeps the username and submits itwith each resolution request, as well as offers the user the option toblock sending the username (for one request or all future requests). Inother words, this particular system is an opt-in system, withcapabilities to opt-out.

Registration Request Message

The Registration Request Message is the interface that defines themessage sent to a Router for data registration. The Registration RequestMessage interface includes an XML Header and Body. Examples are shownbelow, and the format is described below.

Registration Request Root Elements, Sub-Elements and Grouping

Registration request messages choose one root elements from severaloptions, include: <RegistrationCIDRequest> for CreateCID and RegCIDrequest codes; <RegistrationURLRequest> for RegURL, DelURL, RegURLs, andDelURLs request codes; and <RegistrationContactInfoRequest> forUpdateContentProvider, UpdateIDProvider, RegUser and UpdateUser requestcodes. (More root elements may be added when the handling of integer andtext CIDs is finalized, e.g. RegistrationIntCIDRequest andRegistrationTextCIDRequest.) There are sub-elements, including: <Header>for message headers, <Body> for message body, and <PrimaryInfo> and<SecondaryInfo> when needed. Grouping of registration requests isallowed (and it is expected to be specified when the transmissionmethod, e.g. SOAP, is finalized, as discussed below).

Registration Request Message XML Header

The XML header is:

XML Tag Format Description Status Version Integer The version of thisrequest Required message. The current version is 1. IDProviderID IntegerIdentity technology provider Required number as stored in the product(e.g. software) interacting with a Router. IDs 0-511 are reserved (asdescribed below). RequestCode Text Requests a Router to take a Requiredspecified action.

The allowable Request Codes for registration include:

Request Code Description CreateCID Create a unique content ID RegCIDRegister pre-existing CID from other unique identification standardRegURL Register one URL DelURL Delete one URL RegURLs Register severalURLs DelURLs Delete several URLs UpdateContentProvider Update ContentProvider contact information UpdateIDProvider Update ID Provider contactinformation RegUser Register new username, password and contactinformation UpdateUser Update user contact information

-   -   This header data can help the router quickly distribute the        message to various request handlers for the detailed actions to        be handled.    -   The request codes RegURLs and DelURLs register or delete        multiple URLs in one message, which requires less interaction        from the registration software but requires parsing by the        Router.    -   The ID Provider IDs' 0-to-511 are reserved, such as for the case        when the ID Provider embeds their ID within the content since        there are several interoperable readers.

Registration Request Message XML Body

For each Request Code, the Resolution Message XML Body includes thefollowing information.

Request Codes: CreateCID and RegCID

The XML body has primary information, which includes CID relatedvariables, for the registration request, and secondary information whichincludes optional descriptive data for the CID.

The primary request information is:

XML Tag Format Description Status ContentProviderName Text ContentProvider Required name. Password Text Content Required Providerpassword. IDVersion Integer The version of Required the CID algorithm.CID Integer The unique Required or Text content ID formatted as forRegCID integer (preferable) or text, as determined by the ID Version.CIDExpiration Date Expiration Optional date for CID so it can be reused.Use with caution (as described below) Private Binary Binary dataOptional that can be used by the ID Provider for any private reason.

-   -   The CID Expiration field should be used with great caution since        content may exist for a long time. It is most relevant to        temporary content, like news papers or catalogs.

The secondary request information is:

XML Tag Format Description Status Title Text Title of the content.Optional Copyright Text Copyright dates. Optional AdultFlag Boolean TRUEfor adult content, and Optional FALSE for all other content ContentTypeText Content type choices include: Optional audio-music, audio-speech,video videotrack, video-audiotrack, image, and text. ArtistName TextArtist's full name Optional ArtistEmail Text Artist's email addressOptional ArtistPhone Text Artist's phone number Optional ArtistURL TextID Provider, Content Provider or Optional User Artist web page.

Request Codes: RegURL, DelURL, RegURLs and DelURLs

The XML body information is:

XML Tag Format Description Status ContentProviderName Text Contentprovider name. Required Password Text Content provider password.Required IDVersion Integer The ID version provides the Required versionof the CID algorithm. CID Integer The unique content ID formattedRequired or as integer (preferable) or text, according Text to theIDVersion. Primary Boolean TRUE for Primary URL, and Required FALSE forAdditional URLs. URLType Text The URL Type, such as for a Required WAPenabled cell phone or fully functional PC (more details below). URL TextThe URL that links the content to Required more information.URLVariables Text A list of XML tags, separated by Optional a colon “:”,that define the XML fields which are appended at the end of the URL orthe term ALL for all of the request tags (more details below).URLActivation Date Date to activate the URL. If no Optional date is set,the URL is activated, and remains active unless it has expired.URLExpiration Date Date to de-activate URL. If no Optional date ispresent, the URL has no expiration, and is active, unless it has not yetbeen activated. Desc Text Brief description of URL, less Required, than128 characters with spaces except for DelURL and DelURLs Private BinaryBinary data that can be used by Optional the ID Provider for any privatereason.

The allowable URL Types (for all request codes that include this field):

URL Type Code Description Full Fully functional web pages WAP WirelessApplication Protocol (WAP) web page WMI W3C Mobile Web Initiative (MWI)

-   -   The URL Variables enables the URL to deep link into a database.    -   For RegURLs, a list of Primary, URLType, URL, URLVariables,        URLActivation, URLExpiration, and Desc data elements are        separate by semicolons “;”.        -   The field has an entry for each URL (a space for no data is            okay), or not be used at all    -   For DelURL and DelURLs, the data elements in URLVariables,        URLActivation, URLExpiration, and Desc are optional, and are        ignored if included.    -   For DelURLs, a list of Primary, URLType and URL data elements        are separated by semicolons “;”.        -   The other fields, including IDVersion and CID, remains            constant

URLs are categorized into Primary and Additional URLs, where there canbe one Primary URL for each URL Type and as many additional URLs asdesired. This categorization allows immediate redirection for the user,as well as choice of all associated URLs (i.e. additional actions) forthe user. In other words, Primary URLs enable the system toautomatically display the primary web site for the user, thus notrequiring the user to click on the desired URL after selecting toreceive more information. There is a balance, since while reducing thenumber of required clicks, Primary URLs also reducing the choices andretail opportunities.

Request Codes: UpdateContentProvider, UpdateIDProvider, RegUser andUpdateUser

The XML body information is:

XML Tag ormat Description Status RegName Text Content Provider Name,Required Username, or ID Provider ID. The ID Provider ID is converted toan integer inside the router's handler. Password Text ID Provider,Content Provider or Required User password BizName Text Company's fullname Required, except for RegUser and UpdateUser BizEmail Text Company'semail address Optional BizAddress1 Text Company's street address, firstRequired, line except for RegUser and UpdateUser BizAddress2 TextCompany's street address, Optional second line BizCity Text Company'scity Required, except with RegUser and UpdateUser BizState TextCompany's state Required, except with RegUser and UpdateUser BizZip TextCompany's zip Required, except with RegUser and UpdateUser BizCountryText Company's country Required, except with RegUser and UpdateUserBizPhone Text Company's phone number Optional BizURL Text ID Provider,Content Provider or Optional User company web page. BizLogoURL Text IDProvider or Content Provider Optional company logo. BizTemplateURL TextID Provider or Content Provider Optional company template. NameTitleText Contact's name title (e.g. Mr., Ms., Optional etc.) NameFirst TextContact's first name Required NameMiddle Text Contact's middle name orinitial Optional NameLast Text Contact's last name Required NameSuffixText Contact's name suffix (e.g. JR., III, Optional etc.) Email TextContact's email address Required Address1 Text Contact's street address,first line Required, except for RegUser and UpdateUser Address2 TextContact's street address, second Optional line City Text Contact's cityRequired, except for RegUser and UpdateUser State Text Contact's stateRequired, except for RegUser and UpdateUser Zip Text Contact's zipRequired Country Text Contact's country Required Phone Text Contact'sphone number Required, except for RegUser and UpdateUser Cell TextContact's cell phone number Optional Fax Text Contact's fax numberOptional IM Text Contact's instant message Optional address LanguageText Contact's preferred spoken Optional language. Sex Text Contact'sSex (M or Male, or F or Optional Female) Age Integer Contact's AgeOptional Private Binary Binary data that can be used by Optional the IDProvider for any private reason.

-   -   List of countries from Windows XP “Region and Language Options”        in Control Panel    -   List of languages from Windows XP “Region and Language Options”        in Control Panel

Registration Response Message

The Registration Response Message is the interface that defines themessage sent from a Router in response to data registration. TheRegistration Response interface includes a success code, URL and briefdescription of the URL, or error code and associated URL anddescription, as well as private data. Examples are shown below, and theformat is described below.

Registration Response Root Element and Grouping

All registration response messages have one root element of<RegistrationResponse> (and </RegistrationResponse>), and nosub-elements. Grouping of registration requests is allowed (and it isexpected to be specified when the transmission method, e.g. SOAP, isfinalized).

Registration Response XML Message

The registration response message XML format for all requests is:

XML Tag Format Description Status Version Integer The version of thisrequest message. Required The current version is 1. RtnCode IntegerReturn code where “0” means Required success and any positive number asan error code. For this version, the only valid error code is “1”. URLText URL, or list of URLs separated by Optional semicolons “;” Desc TextBrief description of URL or error, Required or list of descriptions ofURLs, with for errors each description or error text having 128characters or less including spaces, and separated by semicolons “;”.Private inary Binary data that can be used by the Optional ID Providerfor any private reason.

-   -   For the RtnCode, error codes, like “2”, may be defined in the        future such that the system can automatically handle the error.        For this version, providing the vendor or user with the error        text is enough, and, thus, “1” is the only valid error code.

Registration Response Message Data

For the request for a unique ID (CreateCID): the message returns a “0”for success in the RtnCode field and the CID in the Desc field—or “1”for error in the RtnCode, the error URL in the URL field, and the errortext in the Desc field.

For the request for registering CIDs from other system ID (RegCID): themessage returns a “0” for success in the RtnCode field—or “1” for errorin the RtnCode, the error URL in the URL field, and the error text inthe Desc field.

For the request to register or delete a URL (RegURL, DelURL, RegURLs,and DelURLs): the message returns a “0” for success in the RtnCodefield—or “1” for error in the RtnCode, the error URL in the URL field,and the error text in the Desc field.

For the request for content provider, ID provider or user registration(UpdateContentProvider, UpdateIDProvider, RegUser, and UpdateUser): themessage returns a “0” for success in the RtnCode field and RegName (e.g.ContentProviderName, IDProviderID, or UserName) in the Desc field foroptional verification—or “1” for error in the RtnCode, the error URL inthe URL field, and the error text in the Desc field.

Content Provider Display

The Content Provider is notified of the success or error. In the case oferror, the error text and URL shall be displayed.

Resolution Interface Specification

The resolution architecture connects the readers to a Router such thatcontent identification can be used to provide users with interestingrelated data and purchasing opportunities.

The resolution interface employs a web services interface.

Secure Authenticated Channel for Request Address

The web services interface uses a secure authenticated channel with theRouter for ResRegAddress and ResResAddress. This protection is requiredto eliminate spoofing of the Router.

Resolution Request Message

The Resolution Request Message is the interface that defines the messagesent to a Router for data lookup. The Resolution Request Messageinterface includes an XML Header and Body. Examples are shown and theformat is described below.

Resolution Request Root Elements, Sub-Elements and Grouping

Resolution request messages choose one of two root elements:<ResolutionURLRequest> for ResURL and ResURLs request codes; and<ResolutionAddressRequest> for ResRegAddress and ResResAddress requestcodes. (More root elements may be added when the handling of integer andtext CIDs is finalized, e.g. ResolutionURLintRequest andResolutionURLtextRequest.) There are sub-elements, including: <Header>for message headers, <Body> for message body, and <PrimaryInfo> and<SecondaryInfo> when needed. Grouping of registration requests isallowed (and it is expected to be specified when the transmissionmethod, e.g. SOAP, is finalized). Grouping is useful when the IDProvider reader can read multiple CIDs embedded in the content (e.g. oneCID from a content owner and one CID from a retailer).

Resolution Request Message XML Header

The XML header is the same as for a registration request. This headerdata can help the router quickly distribute the message to variousrequest handlers for the detailed actions to be handled.

The allowable Request Codes for resolution include:

Request Code Description ResURL Resolve the primary URL ResURLs Resolvethe primary and additional URLs Res2ndInfo Resolve the secondaryinformation ResRegAddress Resolve the address of the Registration Routerfor registration requests ResResAddress Resolve the address of theResolution Router for resolution requests

Resolution Request Message XML Body

For each Request Code, the Resolution Message XML Body includes thefollowing information.

Request Code: ResURL, ResURLs and Res2ndInfo

For these request codes, the message includes primary and secondaryinformation. The Primary Information portion contains the data requiredto properly service the request. The Secondary Information containsuser-specific data and is intended for user specific links and aggregateusage monitoring and reporting.

Privacy issues should be considered when sending the secondaryinformation. Preferably, the user permits the secondary information tobe sent.

The primary request information includes:

XML Tag Format Description Status Timestamp Time Time stamp oftriggering event. Used to a Required id in management of “stale”requests that have timed out. Format is Coordinated Universal Time (e.g.2005-04- 14T13:20:00Z) EmbIDProviderID Integer The ID Provider ID thatembedded the Required if different CID, if different than that of thereader than IDProviderID, software ID Provider ID otherwise blankIDVersion Integer The ID version provides the Required version of theCID algorithm. CID Integer The unique content ID formatted Required oras integer (preferable) or text, as defined Text by the IDVersion.URLType Text The URL Type, such as for a Required, WAP enabled cellphone or fully except for functional PC. Res2ndInfo Response2ndInfoBoolean TRUE if secondary response Required, information is requested,and FALSE if ignored for not. (It is not signaling that secondaryRes2ndInfo request information is included in this request). PrivateBinary Binary data that can be used by Optional the ID Provider for anyprivate reason.

-   -   Private data could, for example, include part of an image or        audio so the server can detect the embedded CID. The binary data        format should be known by the ID Provider handler, as well as        preferably included in the header of the binary data.

The secondary request information includes:

XML Tag ormat Description Status ReaderID Integer A unique ID thatidentifies the reader application per Optional purchase or installation.(More details below) TransactionID Integer A unique ID that identifiesthe transaction for the reader. Optional (More details below) OS TextOperating system, including Windows, WinCE, Optional Mac, Symbian, J2ME,BREW, PALM OS, Microsoft Smartphone/Pocket PC OSVersion Text Request OSfor version from OS and send in same Optional format GPS Text GPScoordinates of requesting device, if available Optional Username TextIdentification of the user and links to data that the Optional user hasregistered sLanguage Text User's preferred spoken language. OptionalsSex Text User's Sex (M or Male, or F or Female) Optional sAge IntegerUser's Age Optional sZip Text User's postal code Optional sCountry TextUser's Country. Optional

-   -   The Reader ID eliminates the statelessness of a Web Services        request and enables useful usage tracking. It is optional due to        privacy concerns and shall be able to be turned off by the user.        -   It can be calculated from the reader machine or pre-assigned            via purchase/activation codes, where the latter is            preferable for mobile devices that may not be able to            generate GUIDs.    -   The Transaction ID provides further tracking upon the reader ID,        and can also be turned off by the user.        -   It can be as simple as starting with 1 and counting each            transaction by that reader.    -   Note that “s” in front of variables means that it is the        secondary information, and allows anonymous data aggregation        without a user registering.        -   If the Username is included, none of these “s” variables are            needed since they have been registered by the user and are            stored in a Router        -   sLanguage uses the list of languages from Windows XP “Region            and Language Options” in Control Panel        -   sCountry uses list of countries from Windows XP “Region and            Language Options” in Control Panel

As such, the following actions are enabled:

-   -   Aggregate usage monitoring and reporting    -   Secondary data about the user to be used for detailed usage        monitoring and user specific resolution responses

Request Code: ResRegAddress and ResResAddress

For this request codes, the message includes:

XML Tag ormat Description Status Timestamp Time Time stamp of triggeringevent. Used Required to aid in management of “stale” requests that havetimed out. Format is Coordinated Universal Time (e.g.2005-04-14T13:20:00Z) ReaderIP Text IP address of the embedder orreader. Required Utilized to determine the correct registration andresolution Router addresses with which to interface.

Resolution Response Message

The Resolution Response Message is the interface that defines themessage from a Router in response to data lookup. The ResolutionResponse interface has primary information, which includes a successcode, URL and brief description of the URL, or error code and associatedtext, and has secondary information which provides content-specificmetadata. Examples are shown below, and the format is described below.

Resolution Response Root Element, Sub-Elements and Grouping

All resolution response messages have one root element:<ResolutionResponse> (and </ResolutionResponse>), and sub-elements of<PrimaryInfo> and <SecondaryInfo>. Grouping of resolution requests isallowed (and it is expected to be specified when the transmissionmethod, e.g. SOAP, is finalized). Grouping is useful when the IDProvider reader can read multiple CIDs embedded in the content (e.g. oneCID from a content owner and one CID from a retailer).

Resolution Response XML Message

The XML primary response information for all requests is:

XML Tag Format Description Status Version Integer The version of thisrequest message. Required The current version is 1. RtnCode IntegerReturn code where “0” means Required success and any positive number asan error code. For this version, the only valid error code is “1”. URLText URL, or list of URLs separated by Required for successfulsemicolons “;” resolution requests, Optional otherwise Desc Text Briefdescription of URL or error, or Required, except for list ofdescriptions of URLs, with Res2ndInfo and each description or error texthaving ResRegAddress and 128 characters or less including ResResAddressspaces, and separated by semicolons “;”. BizLogoURL Text ContentProvider's URL for Optional, except for their company logo. ResURL,ResURLs, and Res2ndInfo if registered by the Content ProviderBizTemplateURL Text Content Provider's URL for Optional, except fortheir desired display template. ResURL, ResURLs, and Res2ndInfo ifregistered by the Content Provider Private inary Binary data that can beOptional used by the ID Provider for any private reason.

-   -   For the RtnCode, error codes, like “2”, may be defined in the        future such that the system can automatically handle the error.        For this version, providing the vendor or user with the error        text is enough, and, thus, “1” is the only valid error code (and        “0” or “1” are the only valid RtnCodes).    -   The URL Variables are added to the URL after a question mark “?”        either as XML data (i.e. between their XML tags) or as text        formatted as XML tag=data, both with colons “:” between the XML        tags        -   XML data            example=<IDVersion>1</IDVersion>:CID=999<CID>999</CID>        -   Text example=IDVersion=1:CID=999        -   Thus, the URL that is returned can point deep inside a            database    -   BizLogoURL and BizTemplateURL are required if they were        registered by the Content Provider and the request code is        ResURL, ResURLs or Res2ndInfo.        -   If they were never been registered, they are optional.

The XML secondary response information for all requests is required forRes2ndInfo request codes or when the Response2ndInfo flag is set:

XML Tag Format Description Status Title Text Title of the content.Required for 2ndInfo request Copyright Text Copyright dates. Requiredfor 2ndInfo request AdultFlag Boolean “1” for adult content, Requiredfor and “0” for all other content 2ndInfo request ContentType TextContent type choices Required for include: audio - music, audio -2ndInfo request speech, video - video track, video - audio track, imageand text. ArtistName Text Artist's full name Required for 2ndInforequest ArtistEmail Text Artist's email address Required for 2ndInforequest ArtistPhone Text Artist's phone number Required for 2ndInforequest ArtistURL Text Artist web page. Required for 2ndInfo requestBizName Text Company's full name Required for 2ndInfo request BizEmailText Company's email Required for address 2ndInfo request BizAddress1Text Company's street Required for address, first line 2ndInfo requestBizAddress2 Text Company's street Required for address, second line2ndInfo request BizCity Text Company's city Required for 2ndInfo requestBizState Text Company's state Required for 2ndInfo request BizZip TextCompany's zip Required for 2ndInfo request BizCountry Text Company'scountry Required for 2ndInfo request BizPhone Text Company's phoneRequired for number 2ndInfo request BizURL Text Company web page.Required for 2ndInfo request

This secondary information comes from a combination of data includedwhen registering a CID and when registering a Content Provider. Althoughthe fields are required for Res2ndInfo or when the Response2ndInfo flagis set, many of the fields are optional when registering and, thus, maynot be returned (or be returned blank) even when requested. Thesecondary information enables the user to view basic artist information,such as may be desirable for photos from a stock agency, and contentprovider information, which is probably desirable for all content.

Resolution Response Message Data

For the request for URL (ResURL): the message returns a “0” for successin the RtnCode field, the primary URL in the URL field, the briefdescription of the URL in the Desc field, and the secondary informationif requested—or “1” for error in the RtnCode, the error URL in the URLfield, and the error text in the Desc field. The Primary URL has beenregistered with the Primary flag set, and matches the requested IDProvider ID, ID Version, CID and URL Type.

For the request for all URLs (ResURLs): the message returns a “0” forsuccess in the RtnCode field, the list of all URLs with the primary URLlisted first, separated by semicolons “;” in the URL field, the list ofbrief descriptions of the URLs, separated by semicolons “;” in the Descfield, and the secondary information if requested—or “1” for error inthe RtnCode, the error URL in the URL field, and the error text in theDesc field. The URLs all match the requested ID Provider ID, ID Version,CID and URL Type. For each URL Type, there is only one primary URL andit is listed first. The secondary information does not have multipleitems in each field since it is linked to the CID and not to the URLs.In other words, the secondary info does not change with URLs, only CIDs.

For the request of secondary information (Res2ndInfo): the messagereturns a “0” for success in the RtnCode field, and the secondaryinformation in the corresponding fields—or “1” for error in the RtnCode,the error URL in the URL field, and the error text in the Desc field.

For the request of the Router address (ResRegAddress and ResResAddress):the message returns a “0” for success in the RtnCode field, the localRouters' web or IP address in the URL field—or “1” for error in theRtnCode, the error URL in the URL field, and the error text in the Descfield.

User Display

When only the primary URL exists, the reader software launches a webbrowser with the primary URL, such that the primary web page is“immediately” displayed for the user. This always happens with ResURL,and may happen with ResURLs.

When requesting multiple URLs, the reader software displays the linksand descriptions with the Content Provider's logo and template, ifBizLogoURL and BizTemplateURL fields have been registered by the ContentProvider. If not, the reader can use its proprietary template. Thetemplate defines which secondary CID information (e.g. title, copyright,adult flag content type, artist info and content provider company info)is displayed. The template uses the corresponding XML tags (in between< >) for the secondary data as variables to display this data.

If the reader is always connected, it should read the CID, requestsecondary information (potentially caching URLs), and then display tothe user that more information is available from <BizName>. Thisapproach causes the response to be immediate upon the user's selectionof more information and removes the chance that the user selects moreinformation and no URLs have been registered. In addition, if thecontent includes multiple CIDs, e.g. one from the content owner and onefrom the retailer, it also enables the user to differentiate theinformation source.

Router Requirements

The following requirements enable the Router system to function properlyand provide value to vendors and users.

CID & URL Requirements

A Router guarantees that requested or registered CIDs are unique for thegiven ID Provider ID and ID Version. For requested CIDs, the generatingalgorithm should guarantee unique IDs. For registered CIDs, the systemchecks the databases to make sure the CID has not already beenregistered by that ID Provider with that ID Version. If it has beenregistered, the system should send back an appropriate error.

When registering URLs, the system checks that a CID has been registeredby the requesting Content Provider name, ID Provider ID and IDVersion.If not, the system should send back an appropriate error.

A Router guarantees that there is only one Primary URL registered foreach URL Type given the ID Provider ID, ID Version and CID.

The Databases include:

-   -   The date that a CID is registered (CIDRegDate) and last modified        (CIDModDate)    -   The date that a URL is registered (URLRegDate) and last modified        (URLModDate)

Log Files and Usage Reports

Log file saves the request time, response delay (in milliseconds),request IP address and registration or resolution XML message, excludingprivate data, for every request. Log files at least span the previous 6months.

The aggregate usage data should be visible to the registered IDProviders and Content Providers via an interactive, secure web site,with abilities to export to excel or delimited (tab or comma) text filesfor download or automatic emailing. Daily, weekly and monthly reportsshall be automatically generated for immediate viewing or export.Monthly usage reports should be kept for the life of the system, dailyand weekly reports for two years.

Reports include:

-   1. For each CID registered by each Content Provider, and for all    CIDs registered by each ID Provider and each Content Provider, for    the requested date range    -   1.1. For all users and users sending secondary information        (including registered users and user sending anonymous secondary        information)        -   1.1.1. Total successful links        -   1.1.2. Aggregate links per date (in the date range)        -   1.1.3. Aggregate links per hour for a 24 hour period        -   1.1.4. Aggregate links per day of the week        -   1.1.5. Aggregate links per IP address        -   1.1.6. Average response time        -   1.1.7. Total unsuccessful links grouped by error code    -   1.2. For users sending secondary information        -   1.2.1. Aggregate links per reader ID (which enables ranking            of anonymous users)        -   1.2.2. Aggregate links per username (which enables ranking            of registered users)        -   1.2.3. Aggregate links per country        -   1.2.4. Aggregate links per zip        -   1.2.5. Aggregate links per sex        -   1.2.6. Aggregate links per age        -   1.2.7. Aggregate links per group        -   1.2.8. Aggregate links per language

The reports allow Content Providers to access CID specific usagestatistics.

The age groups are defined as:

Age Group Code Age Group Description Age 0-5 Users between birth and 5years old Age 6-10 Users between 5 and 10 years old Age 11-15 Usersbetween 11 and 15 years old Age 16-20 Users between 16 and 20 years oldAge 21-25 Users between 21 and 25 years old Age 26-30 Users between 26and 30 years old Age 31-40 Users between 31 and 40 years old Age 41-50Users between 41 and 50 years old Age 51-60 Users between 51 and 60years old Age 61-80 Users between 61 and 80 years old Age 81+ Users over81 years old

The registered vendors shall also be able to create custom reports withany begin and end data in the last 2 years. These custom reports willtake a little time to calculate since daily reports have to be analyzed.The system may allow for custom reports with fields not included in thereport list below for the last 6 months. These reports will take sometime to calculate since they require log files to be analyzed.

Distributed Architecture

In order for the distributed architecture of the Router to functionproperly and be able to be expanded in the future, the following occur.

The reader requests the web or IP address of registration and/orresolution router, which ever are applicable, every week. Thus, thesystem architecture can be dynamically changed every week.

The number of Mirror Routers is set by the Registration Authority. TheMirror Routers forward all registration requests immediately to theCentral Router, and wait its response that the information is correct(or the CID is unique). They also send aggregate usage files to theCentral Router and synchronize with the Central Database daily. Thedaily time is not sent so that they don't all hit the Central Routersimultaneously. Finally, they forward resolution requests for CIDs thatdon't exist in their database and wait for the response beforeresponding to the User, to make sure they were not registered duringthat recent day.

XML Schemas

The XML schemas are specified, most likely, with grouped (e.g., withinWSDL) as follows:

-   -   Registration CID Request Message Schema for CreateCID and RegCID        request codes        -   One for integer and one for text CIDs    -   Registration URL Request Message Schema for RegURL, DelURL,        RegURLs, and DelURLs request codes        -   One for integer and one for text CIDs    -   Registration Contact Information Request Message Schema for        UpdateContentProvider, UpdateIDProvider, RegUser and UpdateUser        request codes    -   Registration Response Message Schema as used by all registration        requests    -   Resolution Request Message Schema for ResURL, ResURLs, and        Res2ndInfo request codes        -   One for integer and one for text CIDs    -   Resolution Request Message Schema for Request Router addresses        via

ResRegAddress and ResResAddress

-   -   Resolution Response Message Schema as used by all resolution        requests        Packing and Transmission methods

The XML packing and transmission methods need to be specified, andinclude http, https, WSDL, SOAP and secure Web Services, such as SAML,WS-License or WS-Security. Public key architecture, such as described inXKMS, X-KRSS, and X-KISS, is probably not required since this exampleimplementation has Content Provider Name and password as part of thestandard XML message interface, and the contact data is not missioncritical.

Importantly, the http or https link should be maintained from request toresponse, and only broken after the response is received, thusincreasing efficiency and reducing risk of firewall interfering with theresponse (as well as not requiring the client embedder or readersoftware to act as a server).

Database Elements Describing the database elements and possiblearrangements helps the reader understand the interface and router sinceit provides an overview of how the requests are handled.

Database Management

Database management is desirable and includes:

-   -   Check URLs at least once a month        -   Report dead URLs to Content Provider (using contact person's            email) whom requested the CID and registered the related URL            -   Uses CID Owner Information        -   Report CIDs with no Primary URL but with additional URLs to            Content Provider            -   This assumes that a CID with no URLs at all has not been                distributed yet or is not used for that URL Type

Database Information

The Primary Databases include the following information. The structuredoes not need to be as implied by the tables. However, the tablesprovide a nice outline and help to conceptually understand how themessage interface is used.

CID Owner Information

Label ContentProviderName IDProviderID IDVersion CID CIDExpirationCIDRegDate CIDModDate Type Text Integer Integer Integer Date Date Dateor Text continued . . . Title Copyright AdultFlag ContentType ArtistNameArtistEmail ArtistPhone ArtistURL Text Text Boolean Text Text Text TextText

-   -   This information is entered when requesting a CID (CreateCID) or        when registering pre-existing CID from another ID standard        (RegCID).        -   the CID for RegCID is checked for uniqueness given ID            Provider ID and ID Version

CID Link Information

Label IDProviderID IDVersion CID Primary URL Type URL URLVariable DescType Integer Integer Integer Boolean Byte Text Text Text or Textcontinued . . . URLActivation URLExpiration URLRegDate URLModDate DateDate Date Date

-   -   This information is entered or removed when a URL is registered        or deleted (RegURL and RegURLs or DelURL and DelURLs),        respectively        -   Check that only one Primary URL for each URL Type is            registered when registering a primary URL with RegURL (as            described in the spec) There may be one database or several            databases        -   There could be a different database for each ID Provider ID,            or ID Provider ID and ID Version.        -   The database could combine ID Provider ID, ID Version, and            CID to one index.            -   There could be two databases, one for numeric                combinations (where CID is an integer) and one for text                combinations (where CID is text based) or one database                with a text index. The registration or resolution schema                could be used to determine which database to use. The                integer combination is optimal for efficiency.    -   Fields may be combined.        -   For example, rather than having URLType, URL and            Description, there may be FullURL, FullDesc, WAPURL,            WAPDesc, WMIURL, WMIDesc—or any combination.    -   The database can convert URL Type text to integer for speed        -   URL Type: Full=1, a WAP=2 and a WMI=3.

The Secondary Databases include the following information:

Content Provider, ID Provider and User Information

Label <RegName>* Password BizName BizEmail BizAddress1 BizAddress2BizCity Type <type> Text Text Text Text Text Text continued . . .BizState BizZip BizCountry BizPhone BizURL BizLogoURL BizTemplateURLText Text Text Text Text Text Text continued . . . Name Email Address1Address2 City State Zip Country Phone Cell Fax Text Text Text Text TextText Text Text Text Text Text continued . . . IM Language Sex Age TextText Text Integer

-   -   <RegName> is ContentProviderName, IDProviderID, or UserName    -   <type> is Text, Integer, or Text for ContentProvider, ID        Provider or User databases, respectively    -   Boolean can be stored with TRUE=1 and FALSE=0    -   Sex can be stored as Boolean with Female=TRUE=1 and Male=FALSE=0

Registration Message Examples

Create a Content ID Request Message (CreateCID) <RegistrationCIDRequest><Header> <Version>1</Version> <IDProviderID>123</IDProviderID><RequestCode>CreateCID</RequestCode> </Header> <Body> <PrimaryInfo><ContentProviderName>Disney</ContentProviderName><Password>walt4pres</Password> <IDVersion>1</IDVersion> </PrimaryInfo><SecondaryInfo> <Title>Fantasia</Title> <Copyright>1960</Copyright><AdultFlag>0</AdultFlag> <ContentType>video-videotrack</ContentType><ArtistEmail>fantasia@disney.com</ArtistEmail> </SecondaryInfo> </Body></RegistrationCIDRequest> Response Message (CreateCID)<RegistrationResponse> <Version>1</Version> <RtnCode>0</RtnCode><Desc>999</Desc> </RegistrationResponse> Register a Pre-Existing ContentID Request Message (RegCID) <RegistrationCIDRequest> <Header><Version>1</Version> <IDProviderID>321</IDProviderID><RequestCode>RegCID</RequestCode> </Header> <Body> <PrimaryInfo><ContentProviderName>Apple</ContentProviderName><Password>1984year</Password> <IDVersion>2</IDVersion> <CID>111</CID></PrimaryInfo> <SecondaryInfo> <Title>Fantasia</Title><Copyright>1960</Copyright> <AdultFlag>0</AdultFlag><ContentType>video-audiotrack</ContentType> </SecondaryInfo> </Body></RegistrationCIDRequest> Response Error Message (RegCID)<RegistrationResponse> <Version>1</Version> <RtnCode>1</RtnCode><URL>http://www.cmds.com/error/error8.html</URL> <Desc>  CID is alreadyregistered. Please verify the CID and ID Version and try again. </Desc></RegistrationResponse>Register multiple URLs

Registering one URL with RegURL is extremely similar except there isonly one data element in the Primary, URLType, URL, URLVariables,URLActivation, URLExpiration, and Desc fields. Alternatively, multipleURLs can be registered by grouping multiple RegURL calls in thetransmission. Deleting one or more URLs with DelURL or DelURLs is verysimilar except that URLVariables, URLActivation, URLExpiration, and Descare optional, and ignored if included. As for RegURL, in DelURL, thereis only one URL included in the URL XML field.

Request Message (RegURLs) <RegistrationURLRequest> <Header><Version>1</Version> <IDProviderID>123</IDProviderID><RequestCode>RegURLs</RequestCode> </Header> <Body><ContentProviderName>Disney</ContentProviderName><Password>walt4pres</Password> <IDVersion>1</IDVersion> <CID>999</CID><Primary>1;1;0;0;0;0</Primary><URLType>Full;WAP;Full;WAP;Full;WAP</URLType> <URL>www.disney.com/fantasia; wap.disney.com/fantasia;www.disney.com/fantasia/music; wap.disney.com/fantasia/music;www.amazon.com/search?fantasia; wap.amazon.com/search?fantasia; </URL><URLVariables> IDProviderID:IDVersion:CID:ReaderID:OS:Username;IDProviderID:IDVersion:CID:ReaderID:OS:Username;IDProviderID:IDVersion:CID:ReaderID:OS:Username;IDProviderID:IDVersion:CID:ReaderID:OS:Username;IDProviderID:IDVersion:CID:ReaderID:OS:Username;IDProviderID:IDVersion:CID:ReaderID:OS:Username; </URLVariables> <Desc>Fantasia movie info from Disney.com; Fantasia movie info from Disney.com(WAP Format); Fantasia music info from Disney.com; Fantasia music infofrom Disney.com (WAP Format); Fantasia memorabilia from Amazon.com;Fantasia memorabilia from Amazon.com (WAP format); </Desc> </Body></RegistrationURLRequest> Response Message (RegURLs)<RegistrationResponse> <Version>1</Version> <RtnCode>0</RtnCode></RegistrationResponse>

Register a User

Updating a Content Provider, ID Provider or User is very similar toregistering a User, except that the name and password have already beenassigned as opposed to being checked for uniqueness. In addition, theUser does not need to enter business information.

Request Message (RegUser) <RegistrationContactInfoRequest> <Header><Version>1</Version> <IDProviderID>123</IDProviderID><RequestCode>RegUser</RequestCode> </Header> <Body><RegName>klevy</RegName> <Password>ken1sgreat</Password><BizName>AIPL</BizName> <BizEmail>levy@aipl.com</BizEmail><BizAddress1>110 NE Cedar Street</BizAddress1><BizCity>Stevenson</BizCity> <BizState>WA</BizState><BizZip>98648</BizZip> <BizCountry>USA</BizCountry><BizPhone>509-427-5374</BizPhone> <BizURL>www.AIPL.com</BizURL><NameFirst>Ken</NameFirst> <NameLast>Levy</NameLast><Email>levy@aipl.com</Email> <Address1>110 NE Cedar Street</Address1><City>Stevenson</City> <State>WA</State> <Zip>98648</Zip><Country>USA</Country> <Cell>509-427-5374</Cell><Language>English</Language> <Sex>M</Sex> <Age>40</Age> </Body></RegistrationContactInfoRequest> Response Message (RegUser) First, theuser receives an error because their username “klevy” exists.<RegistrationResponse> <Version>1</Version> <RtnCode>1</RtnCode><URL>http://www.cmds.com/error/error6.html</URL> <Desc>  Username isalready registered.  Please try a different username. </Desc></RegistrationResponse> Then, they re-try with the user name “kenlevy”,and it is successful. <RegistrationResponse> <Version>1</Version><RtnCode>0</RtnCode> <Desc>kenlevy</Desc> </RegistrationResponse>

Resolution Message Examples Resolve URLs

Resolving one URL is very similar, where the only change is that one URLis returned in the response message.

Request Message (ResURLs) <ResolutionURLRequest> <Header><Version>1</Version> <IDProviderID>123</IDProviderID><RequestCode>ResURLs</RequestCode> </Header> <Body> <PrimaryInfo><Timestamp>2005-04-14T13:20:00Z</Timestamp> <IDVersion>1</IDVersion><CID>999</CID> <URLType>Full</URLType><Response2ndInfo>TRUE</Response2ndInfo> </PrimaryInfo> <SecondaryInfo><ReaderID>789</ReaderID> <TransactionID>235</TransactionID><OS>Windows</OS> <Username>kenlevy</Username> </SecondaryInfo> </Body></ResolutionURLRequest> Response Message (ResURLs) <ResolutionResponse><PrimaryInfo> <Version>1</Version> <RtnCode>0</RtnCode> <URL>www.disney.com/fantasia? IDProviderID=123:IDVersion=1:CID=999:ReaderID=789:ReaderID=789:OS=Windows: Username=kenlevy;www.disney.com/fantasia/music? IDProviderID=123:IDVersion=1:CID=999:ReaderID=789:ReaderID=789:OS=Windows: Username=kenlevy;www.amazon.com/search?fantasia? IDProviderID=123:IDVersion=1:CID=999:ReaderID=789:ReaderID=789:OS=Windows: Username=kenlevy; </URL> <Desc>Fantasia movie info from Disney.com; Fantasia music info fromDisney.com; Fantasia memorabilia from Amazon.com; </Desc><BizLogoURL>disney.com/CMDS/logo.jpg</BizLogoURL><BizTemplateURL>disney.com/CMDS/template</BizTemplateURL> </PrimaryInfo><SecondaryInfo> <Title>Fantasia</Title> <Copyright>1960</Copyright><AdultFlag>0</AdultFlag> <ContentType>video-videotrack</ContentType><ArtistEmail>fantasia@disney.com</ArtistEmail> <BizName>Disney</BizName><BizURL>www.disney.com</BizURL> </SecondaryInfo> </ResolutionResponse>

Resolve Router Address

Requesting the registration router address is very similar, where onlythe request code changes.

Request Message (ResResAddress) <ResolutionAddressRequest> <Header><Version>1</Version> <IDProviderID>123</IDProviderID><RequestCode>ResResAddress</RequestCode> </Header> <Body><Timestamp>2005-04-14T13:20:00Z</Timestamp><ReaderIP>206.58.236.61</ReaderIP> </Body> </ResolutionAddressRequest>Response Message (ResResAddress) <ResolutionResponse> <PrimaryInfo><Version>1</Version> <RtnCode>0</RtnCode><URL>198.70.207.6/CMDS/cgi_bin</URL> </PrimaryInfo></ResolutionResponse>

Error Text Examples

Some error text examples include:

-   1. “Content is registered, but no URL in database. Please contact    <ContentProviderName> at <BizEmail>.”-   2. “Content is registered, but URL is marked as inactive. Please    contact <ContentProviderName>.”-   3. “No record in database matching the content. Please contact    <ContentProviderName> at <BizEmail>.”-   4. “Request format error—incomplete data. Please contact software    provider.”-   5. “Primary URL is already registered. Please try again and verify    settings, especially Primary and IDVersion.”-   6. “Username is already registered. Please try a different    username.”-   7. “Password is not a valid format. It needs to be at least 6    characters with a number. Please try again.”-   8. “CID is already registered. Please verify the CID and ID Version    and try again.”-   9. “CID is not registered. Please verify the Content Provider Name,    ID Version and CID.”-   10. “CID is expired as content is out of date.”

The system is very flexible and can enable multiple futurepossibilities. The enhancements include: (1) seed and interoperatemultiple ID systems, and (2) enabling “buy now” links for illegitimatecontent. Another enhancement includes integrating multiple ID Providertechnologies or cached Routers.

Seed and Interoperate with Multiple ID Systems

In a future version of the messages (e.g. with the number “2” in theVersion XML header tag), the following steps could enable this system toseed and interoperate with multiple ID systems:

1. Add a registration request code to register other IDs that are linkedto a CID

2. Add a resolution request code to return the other IDs

3. Add a resolution request code to return the CID given the other ID

Even when the other IDs are returned, the receiving software needs toknow how to register the other IDs with each proprietary system toenable seeding multiple systems from one piece of software.

Registration Request Message

Specifically, the following request code could be added to version 2 ofthe registration message:

Request Code: RegOtherIDs

XML Tag Format Description Status ContentProviderName Integer Contentprovider name.

equired Password Text Content provider password.

equired IDVersion Integer The ID version provides the version of the CID

equired algorithm. CID Text The unique content ID formatted according tothe Required IDVersion. Since these requests are few, speed is notcritical and integer CIDs are carried as text. W3C_URI Text World WideWeb Consortium (W3C) Uniform Resource Optional Identifier (URI).http://www.ietf.org/rfc/rfc2396.txt. Format is text. IDF_DOI TextInternational DOI Foundation (IDF) Digital Object Identifier Optional(DOI). www.doi.org. Format is text. OASIS_ERI Text OASIS's unique ID.http://www.oasis-open.org/who/ Format Optional is text. CISAC_CISInteger International Confederation Of Societies Of Authors And OptionalComposers (CISAC) Common Information System (CIS). http://www.CISAC.org.Format is 96 bits. ISO_ISRC Text (12 The ISRC (International StandardRecording Code) was Optional chars) developed by ISO (InternationalOrganisation for Standardisation) to identify sound and audio-visualrecordings. It is known as International Standard ISO 3901.http://www.iso.ch/cate/d9515.html. Format is 12 characters. SMPTE_UMIDInteger Society of Motion Picture Television Engineers (SMPTE) OptionalUnique Material Identifier (UMID). www.smpte.org 330M- 2000. Format is64 bits. ISO- Text Moving Pictures Expert Group (MPEG) Digital ItemOptional IEC_MPEG21_DII Identification (DII). ISO/IEC 21000-3. Format istext. ISO_ISAN Integer ISO International Standard Audiovisual Number(ISAN). Optional http://www.nlc-bnc.ca/iso/tc46sc9/isan.htm. Format is64 bits. ISO_V-ISAN Integer ISO Identifier for Versions of Audiovisualworks. w4636 Optional Format is 96 bits. ISO_ISWC Text (9 ISOInformation System Work Code (ISWC). Optional chars)http://www.iswc.org. Format is 9 digits. cIDf Integer Content ID Forum(cIDf). www.cidf.org. Format is 96 bits. Optional IFPI_Grid Text (18IFPI Global Release Identifier (GRid). www.ifpi.org/grid. Optionalchars) The format is 18 characters. EBU_WUMI Integer European BroadcastUnion (EBU) Watermark Unique Optional Material Identifier (WUMI).http://www.ebu.ch. Format is 64 bits. Ad-ID Text (12 Ad-ID LLC'sadvertising ID. www.aaaa.org. Format is 12 Optional chars) characters.TVAnyTime_CRID Text TV Anytime's unique identifier.http://www.tv-anytime.org. Optional Format is text. CRF Text ContentReference Forum (CRF). www.crforum.org. Optional Format is text.ISO_ISBN Integer ISO International Standard Book Number (ISBN). Formatis Optional (10 10 digits. digits) ISO_ISSN Integer ISO InternationalStandard Serial Number (ISSN). Format Optional (8 digits) is 8 digits.ISO_ISTC Text ISO International Standard Textual Work Code. Format isOptional text (since not sure of format). ONIX Text ONline InformationeXchange (ONIX) Optional http://www.editeur.org/onix.html. Format istext (since not sure of format). UCC_UPC Integer Uniform Code Council(UCC) Universal Product Code Optional (12 (UPC) www.uc-council.org.Format is 12 digits. digits) EPCGlobal_EPC Integer EPCGlobal ElectronicProduct Code (EPC). Optional www.EPCGlobal.com. Format is 96 bits.Symbol_PDF417 Array Symbol 2D bar code standard. Portable DocumentFormat Optional (1.1 kBytes) (PDF). Format is 1.1 kBytes. Private BinaryBinary data that can be used by the ID Provider for

ptional any private reason.

indicates data missing or illegible when filed

Registration Response Message

For the request for registering other system ID (RegOtherIDs): themessage returns a “0” for success in the RtnCode field—or “1” for errorin the RtnCode, the error URL in the URL field, and the error text inthe Desc field.

Resolution Request Message

The following resolution request codes could be added, with thecorresponding response data:

Request Code: ResCIDGivenOtherID

This request uses the same format as used in ResURL, except the CID XMLfield contains the other ID data (and the CID is returned).

Request Code: ResOtherIDs

This request includes primary information, and uses the same data as forRegOtherIDs, except that the Content Provider ID and Password XML tagsare optional. In addition, the Timestamp XML tag from the ResURL RequestCode above is included as required fields.

Resolution Response Message

For requesting a CID given another unique ID (ResCIDGivenOtherID): themessage returns a “0” for success in the RtnCode field, the CID in theDesc field, and the secondary information if requested—or “1” for errorin the RtnCode, the error URL in the URL field, and the error text inthe Desc field.

For requesting other unique IDs (ResOtherIDs): the message returns a “0”for success in the RtnCode field, and a list of the registered other IDswith each entry separated by a semicolon “;” each entry in the formatconsisting of the other system XML tag as defined for RegOtherIDsrequest code and related ID separated by a colon “:” in the Desc field,and the secondary information in the corresponding fields ifrequested—or “1” for error in the RtnCode, the error URL in the URLfield, and the error text in the Desc field.

Database Elements

The corresponding database elements could be:

Unique ID Systems Database

W3C IDF OASIS Label IDProviderID Version CID URI DOI ERI Size IntegerInteger Integer Text Text Text or Text continued . . . ISO/IEC CISACSMPTE MPEG21 ISO ISO CIS ISRC UMID DII ISAN VISAN Integer Text IntegerText Integer Integer (96 bits) (12 (64 bits) (64 bits) (96 bits) chars)continued . . . TV ISO IFPI EBU AnyTime ISWC cIDf Grid WUMI Ad-ID CRIDCRF Text Integer Text Integer Text Text Text (9 (96 bits) (18 (64 bits)(12 digits) chars) chars) continued . . . ISO ISO ISO UCC UCC SymbolISBN ISSN ISTC ONIX UPC EPC PDF 417 Integer Integer Text? Text? IntegerInteger Array (10 (8 (12 (96 bits) (1.1 digits) digits) digits) kBytes)

“Buy Now” for Illegitimate Content

When the multimedia player goes to play or transfer raw content (i.e.neither encrypted nor digitally signed), it calls the reader plug-in tocheck for a CID and whether or not the content is copy protected. Ifthis raw content is copy protected and contains a CID, an explanationand “buy now” link can be provided to the user.

Note that the existence of a CID does not necessarily mean that thecontent cannot be played, as the consumer may have converted a purchasedCD to compressed audio, or bought non-encrypted content. The contentneeds to also have a copy protection identifier, such as Copy ControlInformation (CCI) in the content ID, such as DWM, payload. The Playercan log this event so it only checks raw content once.

By including a rights' flag linked to URLs, one primary rights URL canbe registered using existing registration requests, and the rights URLcan be returned to the reader to offer a “buy now” link to purchaselegitimate content. Specifically, the rights flag is an additional XMLfield in registration and resolution messages, and is included in thedatabase elements with the URLs.

Universal Reader Interface

When content owners and retailers are both acting as Content Providers,thus, both marking the content with their own CID, the user sees twodifferent “more info” buttons, one from the content owner and one fromthe retailer. There could even be an additional “more info” button fromthe distributor, such as ISP.

The Registration Authority could, in the future, provide a plug-in thatprovides a universal reader interface that integrates CIDs and URLs fromdifferent ID Provider detectors. This example implementation could beexpanded to include a standard reader-application interface, which isthe interface between a generic reader plug-in and ID Provider detector.Thus, all installed ID technology detectors could call (or be calledfrom) the generic reader plug-in, and all CIDs sent to a Router from thegeneric reader plug-in.

Not only would the interface be specified for this generic readerplug-in, but the Registration Authority would also have to provide theplug-in for distribution for all multimedia players. The generic plug-incould have the ID provider plug-ins call it with their resolutionrequest XML messages, then display one “more info” button for the user,and finally send requests for all detected CIDs to a Router. Thisapproach would only require the ID Provider plug-ins to change theircall from an IP address to an internal DLL, and remove their userdisplay.

Cached Routers

The architecture enables Mirror Routers to link to Cached Routers forresolution requests. Cached Routers are not applicable to registrationrequests since these requests occur neither often nor repetitively, andare immediately forwarded to the Central Router. These Cached Routerswill temporarily maintain their Cached Database for recent resolutionrequests. It is expected that the data will have a time limit set by theRegistration Authority. The Cached Routers will also send usageinformation to their linked Mirror Router daily. This architecturebecomes truly distributed and efficient.

CONCLUDING REMARKS

Having described and illustrated the principles of the technology withreference to specific implementations, it will be recognized that thetechnology can be implemented in many other, different, forms. Toprovide a comprehensive disclosure without unduly lengthening thespecification, applicants incorporate by reference the patents andpatent applications referenced above.

The methods, processes, and systems described above may be implementedin hardware, software or a combination of hardware and software. Forexample, the auxiliary data encoding processes may be implemented in aprogrammable computer or a special purpose digital circuit. Similarly,auxiliary data decoding may be implemented in software, firmware,hardware, or combinations of software, firmware and hardware. Themethods and processes described above may be implemented in programsexecuted from a system's memory (a computer readable medium, such as anelectronic, optical or magnetic storage device).

The particular combinations of elements and features in theabove-detailed embodiments are exemplary only; the interchanging andsubstitution of these teachings with other teachings in this and theincorporated-by-reference patents/applications are also contemplated.The inventor submits that the invention encompasses the claims set forthbelow, as well as systems and computer readable mediums that implementthese methods. The embodiments described in this document are alsoinventive and applicant reserves the right to claim various embodimentsand combinations thereof as its invention.

1. A system processing product packaging, the method comprising: adatabase system comprising one or more computers configured withinstructions to register different content ID schemas of differentmobile device application programs, the registering of the differentcontent ID schemas comprising registering ID provider identifierscorresponding to the different content ID schemas; in the databasesystem, registering a set of identifiers for each of the differentcontent ID schemas, wherein the identifiers in a content ID schemacorrespond to packaging encoded with identifiers from the content IDschema, and the identifiers are encoded in the packaging; and aprogrammed processor configured with instructions for handling metadatarequests from plural reader programs, wherein the plural reader programsare installed within the mobile device application programs in memory ofmobile devices, each of the mobile devices configured with instructionsof a reader program to receive an image signal sensed by the mobiledevice and decode digital data from the image signal sensed from thepackaging; the program processor configured with instructions to processa metadata request to obtain a ID provider identifier, and at least afirst identifier extracted from a first image signal by a requestingmobile device making the metadata request; the programmed processorfurther configured with instructions to route the requesting mobiledevice to a metadata response identified by the ID provider identifierand the first identifier extracted from the first image signal.
 2. Thesystem of claim 1 wherein a first content ID schema is determined fromthe ID provider identifier provided by a first reader program used toextract the first identifier from the first image signal.
 3. The systemof claim 1 wherein the identifiers of different content ID schema arederived from an image signal using different ID provider detectors. 4.The system of claim 3 wherein the different ID provider detectors areinstalled within the first reader program.
 5. The system of claim 4wherein the first reader program comprises a plug-in of a first mobiledevice application program.
 6. The system of claim 1 further comprisinga traffic monitor, the traffic monitor comprising a programmed processorconfigured with instructions to log usage data from the metadatarequests.
 7. The system of claim 6 wherein the traffic monitor isconfigured to track the packaging, by tracking identifier detection bythe mobile applications and user identification of the mobile devicesexecuting the mobile applications, the tracking identifying flow of anobject in a distribution channel.
 8. A system processing productpackaging, the method comprising: a database system comprising one ormore computers configured with instructions to register differentcontent ID schemas of product packaging, the registering of thedifferent content ID schemas comprising registering ID provideridentifiers corresponding to the different content ID schemas; in thedatabase system, registering a set of identifiers for each of thedifferent content ID schemas, wherein the identifiers in a content IDschema correspond to packaging encoded with identifiers from the contentID schema, and the identifiers are encoded in the packaging; aprogrammed processor configured with instructions for handling metadatarequests from reader programs, wherein the reader programs are installedwithin the mobile device application programs in memory of mobiledevices, each of the mobile devices configured with instructions of areader program to receive an image signal sensed by the mobile deviceand decode digital data from the image signal sensed from the packaging;the program processor configured with instructions to process a metadatarequest to obtain a ID provider identifier, and at least a firstidentifier extracted from a first image signal by a requesting mobiledevice making the metadata request; the programmed processor furtherconfigured with instructions to route the requesting mobile device to ametadata response identified by the ID provider identifier and the firstidentifier extracted from the first image signal; and a traffic monitor,the traffic monitor comprising a programmed processor configured withinstructions to log usage data from the metadata requests; the trafficmonitor configured to track the packaging, by tracking identifierdetection by the mobile applications and user identification of themobile devices executing the mobile applications, the trackingidentifying flow of an object in a distribution channel.
 9. The systemof claim 8 wherein a first content ID schema is determined from the IDprovider identifier provided by a first reader program used to extractthe first identifier from the first image signal.
 10. The system ofclaim 8 wherein the identifiers of different content ID schema arederived from an image signal using different ID provider detectors. 11.The system of claim 10 wherein the different ID provider detectors areinstalled within the first reader program.
 12. The system of claim 11wherein the first reader program comprises a plug-in of a first mobiledevice application program.
 13. A system processing product packaging,the method comprising: a database system comprising one or morecomputers configured with instructions to register different content IDschemas of product packaging, the registering of the different contentID schemas comprising registering ID provider identifiers correspondingto the different content ID schemas; in the database system, registeringa set of identifiers for each of the different content ID schemas,wherein the identifiers in a content ID schema correspond to packagingencoded with identifiers from the content ID schema, and the identifiersare encoded in the packaging; a programmed processor configured withinstructions for handling metadata requests from reader programs,wherein the reader programs are installed within the mobile deviceapplication programs in memory of mobile devices, each of the mobiledevices configured with instructions of a reader program to receive animage signal sensed by the mobile device and decode digital data fromthe image signal sensed from the packaging; the program processorconfigured with instructions to process a metadata request to obtain aID provider identifier, and at least a first identifier extracted from afirst image signal by a requesting mobile device making the metadatarequest; the programmed processor further configured with instructionsto provide the requesting mobile device with metadata identified by theID provider identifier and the first identifier extracted from the firstimage signal; and a traffic monitor, the traffic monitor comprising aprogrammed processor configured with instructions to log usage data fromthe metadata requests; the traffic monitor configured to track thepackaging, by tracking identifier detection by the mobile applicationsand user identification of the mobile devices executing the mobileapplications, the tracking identifying flow of an object in adistribution channel.
 14. The system of claim 13 wherein a first contentID schema is determined from the ID provider identifier provided by afirst reader program used to extract the first identifier from the firstimage signal.
 15. The system of claim 13 wherein the identifiers ofdifferent content ID schema are derived from an image signal usingdifferent ID provider detectors.
 16. The system of claim 15 wherein thedifferent ID provider detectors are installed within the first readerprogram.
 17. The system of claim 16 wherein the first reader programcomprises a plug-in of a first mobile device application program.